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I. INTRODUCTION 



A. BACKGROUND 

LISP Is often associated with Artificial Intelligence (Al) and its many 
Intriguing possibilities. Al has roots that extend deeply Into philosophical 
thought and perhaps originated with Hobbe’s view of thinking as 
computation. But, can machines think? Perhaps It's just that engineers 
haven’t been able to design them to do 1t.^ Or, maybe, the circuits to make 
such machines are Inordinately huge and complex. If this Is the case, then 
computers can be used to automate part of the design process and speed 
things up. For example, a silicon compiler Is a program that takes a high 
level description of an electronic circuit’s behavior or function and outputs 
a VLSI Implementation. 

Up to now though, silicon compilers have traded off chip efficiency for 
design time. Their products don’t compete well with handcrafted chips. Can 
Al techniques remedy this situation? In other words, can the silicon 
compilers be made -smarter? It seems that the attribute of Intelligence, 
which Is Al’s goal. Is needed now. In order to create the basis for creating 
Itself. 

This Is a thorny problem which crops up over and over In current Al 
projects and which has plagued philosophical thought for thousands of years. 

1 Richard Hamming. To balance this out, he adds; “Just because you wish to 
believe that computers can think does not mean that they can.’’ 
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Modem philosophers like Dreyfus, Haugeland, Heidegger, Husserl and 
Wittgenstein take different stances on what constitutes intelligence.^ 

In the meantime, success in war and peace depends on computers. 
Sensors, controllers and actuators melded into smart machines build cars 
round the clock or kill at long range. Additionally, computing machines 
process data used in all phases of decision making. The range of use extends 
from simple word-processors up to expert consultants. 

However, the potential use of computers has only begun to be explored. 
And, though there have been many impressive results from computer expert 
systems, they have been limited to specific domains of expertise. Therefore, 
in order to break through to a new level of processing activity, the Defense 
Advanced Research Projects Agency (DARPA) launched a major Strategic 
Computing (SC) program. (DARPA, 1983, pp 1-18) 

SC has a goal of creating a widespread machine intelligence technology 
in the United States. It aims at creating a prototype autonomous land 
vehicle, a pilot's associate and a battle management system. The SC program 
is multi-level and addresses issues from microelectronics to software 
design. However, several areas, such as vision and speech recognition, which 
humans do so effortlessly, are difficult for machines with present 
approaches as indicated in this quote (DARPA, 1983, p. 33): 

Recent progress in developing vision for navigation has been severely 
constrained by lack of adequate computing hardware. Not only are the 
machines which are now being used too large to be carried by the 
experimental vehicles, but current machines are far too slow to execute 
the vision algorithms in real-time 



2 See the bibliography. 
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It is estimated that 1 trillion von Neumann equivalent computer 
operations per second are required to perform the vehicle vision task at a 
level that will satisfy the autonomous vehicle project's long-range 
objectives. At best, current machines of reasonable cost achieve 
processing rates below 100 million operations per second. The required 
factor of 10^ improvement in speed will have to be achieved through VLSI 
implementation of massively parallel architectures. 

The creation of new software methodologies for parallel computation 
and a shift of present software structures into VLSI circuits is creating 
more powerful processing structures. These may or may not lead to thinking 
machines, but they will certainly change the nature of computation. 
Paraphrasing Richard Hamming: If you believe computers can’t think, you’re 
probably right; but, if you don’t do anything about it, you will be left far 
behind. 

Therefore, in order to understand where automatic VLSI design tools can 
be enhanced in order to accelerate the development of new processors, two 
existing silicon compilers were investigated. 



B. SCOPE OF THIS THESIS INVESTIGATION 

The MacPitts silicon compiler has been previously studied at the Naval 
Postgraduate School mainly from the user's point of view. (Carlson, 
1984)(Froede, 1985)(Larrabee, 1985) From these studies two things became 
evident: 

(1) The user Interface to MacPitts can be made more accessible 
to the systems engineer. 

(2) Changes to the compiler require a study of the LISP code it 
is written in. 
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The first problem is addressed by creating a flowchart interface in 
which the user graphically creates state diagrams that are converted for 
the user into MacPitts programs. (Weist, 1986) 

The second issue is the subject of this thesis: an examination of Lincoln 
Laboratory’s LISP based Layout Language (L5) and its relation to MacPitts. 
L5 is a LISP based language used by MacPitts to compile Very Large Scale 
Integrated (VLSI) circuits automatically. L5 is also used by the Lincoln 
Boolean Synthesizer (LBS), a Complementary Metal Oxide Semiconductor 
(CMOS) compiler of arbitrary boolean expressions, to generate combinational 
logic circuits. 

Both of these compilers have many interacting programs linked together 
to execute automatically. Alteration of this behaviour requires that the 
programs, composed of L5 and LISP code, be modified. 

Therefore, the main questions examined in this thesis are: 

• How is L5 created? 

• How is L5 used? 

The answer to these questions is given by: 

• Introducing LISP; 

• Covering LISP extensions needed to create L5 (lincoln.l); 

• Presenting L5; 

• Grouping several programs into a “compiler"; and, 

• Modifying a MacPitts functional unit. 

LISP fundamentals are covered in Chapter II. The ideas of functional 
programming and other general concepts are discussed. After this overview, 
the presentation covers LISP functions and usage. Additionally, a look is 
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taken at debugging tools available in the Franz Lisp programming 
environment. 

In Chapter III a program that contains many of the basic functions used 
in LBS and NacPitts, lincoln.l, is presented. The key concept in lincoln.l is 
the data structure generation macro defstnict. This macro is an example 
of a LISP function that creates other LISP functions. It is the method used 
throughout both compilers to generate easily manipulated data structures. 

From the discussion of extensions made to the LISP language in lincoln.l. 
Chapter IV moves on to L5. The primitive layout objects, items, and their 
data structures are shown. The functions which are used in L5 to generate 
complex structures out of these basic items are illustrated. The 
interrelationship of L5 with two other hierarchically organized formats, 
Caesar and CIF, is also covered. 

After this. Chapter V deals with linking a group of LISP programs into an 
environment which the user can run as an integrated system. The examples 
used are the LBS and MacPitts top-level functions. These functions control 
program execution. 

In Chapter VI a modification to a MacPitts functional unit, an organelle, 
is described. The material in this chapter covers enough of MacPitts to 
enable the user to experiment with changing MacPitts' data-path. However, 
once these basic ideas are understood, then other portions of the compiler 
can also be changed. 

The last chapter. Chapter VII, presents thesis conclusions and contains 
suggestions for future work. 
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Appendix A contains a description of alignment proPlems caused by 
incorrect CIF plotting or organelle specification; and, a sketch of how to 
experiment in the MacPitts environment. 

In summary, this thesis covers L5, a flexible idiom for procedurally 
creating VLSI circuits, and shows how understanding L5 makes MacPitts and 
LBS accessible for modification. 
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II. THE LISP ENVIRONMENT 



LISP is a flexible language with a rich set of programming tools. It can 
be run interactively or it can be compiled. LISP allows interpreters for 
other languages to be easily written. For example, both Macpitts' and LBS's 
interpreters are LISP based. The following quote summarizes some other 
reasons for learning LISP (Hofstadter, 1985, p. 450): 

Beginners in Lisp encounter . . . fundamental issues in computer science 
that even some advanced programmers in other languages may not have 
encountered or thought about. Such concepts as lists, recursion, side 
effects, quoting and evaluating pieces of code ... are truly central to the 
understanding of the potential of computing machinery. 

This chapter examines these ideas, shows LISP’S applicative [functional] 

nature and briefly covers LISP'S lexicon. The last chapter section is an 

introduction to useful LISP program development tools. 

A. LISP: A FUNCTIONAL PROGRAMMING LANGUAGE 

This section covers functional programming and introduces a concise 
language for talking about program syntax [Backus Naur Format]. A look is 
taken at LISP’s basic functional form [lambda notation) and the issues 
associated with passing parameters into functions. The problem of variable 
scoping is also covered. Finally, a brief comparison of iteration and 
recursion is given. 
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Imperative languages are based on directing control through a series 
of assignment statements. LISP on the other hand applies functions to their 
arguments. (hacLennan, 1983, p. 345) 

A function takes a combination of arguments and assigns a unique 
value to it. A functional or applicative language^ is built upon a simple 
idea that is well illustrated in this quote (Hofstadter, 1985, p. 452) : 



A programmer's instinct says that you con cumulatively build a system, 
encapsulating all the complexity of one layer into a few functions, then 
building the next layer up by exploiting the efficient and compact 
functions defined in the preceding layer. This hierarchical mode of buildup 
would seem to allow you to make arbitranly complex actions be 
represented at the top level by very simple function calls. 

'This spirit of functional application pervades both MacPitts and LBS. 
But, before looking at LlSP’s functions, a language for talking about LISP, 
Backus Naur Format, is Introduced. 

2. Backus Naur Format (BNF) 

BNF is a concise set of symbols for describing the syntax of computer 
languages. Its key idea is that the description should look like the language 
it's talking about (MacLennan, 1983, pp. 166-173). A terse set of BNF 
symbols is given below: 



• The ' < “ and " > " indicate syntactic categories. For example, <integer>, 
<LISP form>, etc.. 



• The ’ ;:= " means " is defined as 



1 Haugeland, 1984, pp. 125-164 gives a very cogent explanation of 
several computer architectures (LISP included). 
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• A straight line, " I stands for " or 



a Square brackets, " ( " and 



", indicate optional parameters. 



• An asterisk, " * " is equivalent to " a sequence of zero or more " 



• A " means " a sequence of one or more " 

• Braces. " { " and " } " are used to group syntactic classes and say " a 
sequence of <classi>s or <class 2 >s, etc.". 

• Many US? symbols represent themselves. For example the LISP prompt 
sign “ -> " or LISP parenthesis " ( " and " ) 

Consider an example that creates a class of <other character's 
<other character) ;;= + I - I _ 1 % I i I ?| I * I @ 

-in other words, the <other character>s are; + or - or _ or % or J, etc 
Another class is <alphanumeric>s, defined as follows: 

<alphariurneric> :;= <letter> I <digit> 

Therefore, an <alphanurneric> is either a <letter> or a <digit> a 
special LISP object, an atom, is defined as a sequence of previously def iiied 
objects in the following manner. 

<atom> {<other character) I <alphanurneric)}'^ 1 i) 

An atom is a sequence of one or more <other character>s or 
<alphariurneric)S; or, (). The empty atom, (), is called nil. [Haserner, 1964, 
p. 51 (Refer also to Table 2.1 and Figure 2.2 in Section II.B 1 b] Atoms are 
basic LISP building blocks. 



~ " -> " is Franz Lisp's prompt sign. " ( " and " ) " respectively start and 
top LISP'S interpretation of an instruction. See Section II.B. 1. a for an 
xplanation. 
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<list>2 .:= (<atorn>*) i ({<atorn> I 



A iist is a left parenthesis followed 'with zero or more atoms or 
lists, closed off with a right parenthesis. Notice that this is a recursive 
definition: a <list> is defined in terms of itself. Examples of lists are: 

0, (a), (a b (c d) a). 

Note that 0, nil, is both an atum and a list. 

BMP is used throughout this thesis to describe LISP syntax. LlSP's 
basic functional format. <larribda function>, can now be analyzed. 

3. Lambda Functions 

One method for writing functions in LISP is with lambda notation. [For 
other-:function definition formats see Section II.C.2] Perhaps the easiest 
way to understand lambda notation is with this quote showing its history 
(Touretzky, 1964, p. 56); 

Lambda notation was created by Alonzo Church, a mathematician at 
Princeton University, as an unambiguous Y/ay of specifying functions, their 
inputs, and the computations they perform. In lambda notation, a function 
that added 3 to a number would be written Xx.(3 + x). The X is the Greef^ 
letter lambda. 



2 Refer to Sections II.C. 1 and II.C.3.b. A list can also be viewed in this 



light: 



<list> :;= (<headxtail>) 
<head> ::= { <atorn> I <list> } 
<tail> ;:= <list> 



For example; 



0 

(a) 



(a) has <head> ;= a and <tail> ;= nil 

(a b (c d) e) has <head> := a and <tail> := (b (c d) e) 



has <head> := nil and <tail> := nil 
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John ncCarthy, the 
>pecifying functions. 



X • t 't 1/^ 

f V A/ \ 0 



list 



origiridtor of Lisp, adopted Church's notation for 
The Lisp equivalent of the unnarricd function 



(LAMBDA (X) (PLUS 3 X)) 

A function F(x,y) = 3x + y2 would be written X(x,y).(3x + y^) in lambda 
notation. In Lisp it is written 

(LAMBDA (X Y)(PLUS (TIMES 3 'X) (TIMES Y Y))) 

Lambda notation creates functions in LISP with this syntax; 

<lamfcda function> ;:= 

(lambda (<argument>*)<LISP form>) 
<LISP form> ::= {<atom> ! <list>}‘^ 

<argument> <atom> 

-A lambda function is used [applied to parameters] to obtain a ■•'alue 
with this format: 



<value> ;;= -> (<lambda functionxparameter>*)<CP>‘^ 
<value> ::= <LISP forrn> 

^parameter> ;:= <LISP form> 

Therefore, to apply the function F(x,y) = 3x + y2 with x=2 and ij=3 in 
LISP, the user types; 

-> ((lambda (» y)(plus (times 3 H)(times y y))) 2 3)<CP; 

;; ((lambda (x y)(plus (times 3 x'Xtimes y y))) <x> <y>) 

;;5 This function is equivalent to; 

„ (^ (* 3 2)(* 3 3)) = (^6 9)= 15 

15 

That is to say, that the value resulting from F(2,3) is equal to 15. 



<CR> IS an abbreviation for the action of hitting a "carnage return" 

5 LISP ignores anything on a line after a semicolon; therefore, one or 
more semicolons " ; " are used to insert comments into LISP programs 
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The lambda function format can be named by using the LISP primitive 
dcf^ in this manner: 

<function-name> ::= 

-> (def <function-name> <lambda function>) <CR> 
<function-name> ::= <atom> 

A function created with def is applied to its argument's parameters 
by using its name as follows: 

<value> :;= -> j(<function-name><parameter>*)<CR> 

By naming the function, its usefulness is increased. Instead of typing 
the unwieldy lambda form each time the function is applied, the user simply 
types in the function's name. Consider F(x,y) = 3x + y2 defined as a LISP 
function named quadratic: 

-> (def quadratic 

;; <function-name> ::= -> (def <function-namexlambda function>) 

(lambda (u y) 

(plus (times 3 uHtimes y y))))<CR> 

;; LISP returns <function-name>: 

quadratic 



This function, quadratic, is applied by using its name with 
parameters: 

-> (quadratic 2 3)<CR> 

;; (quadratic <xxy>) 

15 

-> (quadratic (quadratic -1 2)(quadratic 2 3))<CR> 

;; (quadratic -1 2) := 1 & (quadratic 2 3):= 15 
;; (quadratic 1 15) := 228 
228 



6 See Section II.C.2 for another method for defining functions ( defun ]. 
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The following question now arises: If functions are nested and values 
passed from function to function, then how are the values of these variables 
being controlled? That Is to say, the above computation assumed this 
structure: 

(quadratic <xxy>) 

/ \ 

(quadratic <xxy>)(quadratic <xxy>) 

II II 

-12 2 3 

Figure 2.1 Passing of Values In Nested Functions 

But, why not some other method? The next section examines 
established conventions for passing values and calling variables. 

4. Variable Scoping 

The context in which a variable is called can in fact affect its value. 
The method used to call up a variable and limit Its scope will determine the 
value that is used. To examine these ideas a few definitions are needed 
(Rosenberg, 1984, pp. 62, 165, 460, 501, 570): 

call by reference: a subroutine or procedure call where the addresses 
of the parameter’s storage locations are passed to the subroutine. 

call by value: a subroutine or procedure call where the actual values of 
the parameters are passed to the subroutine. 

dynamic: occurring at the time of execution. 

scope (of a variable): the portion of a computer program within which 
the definition of the variable remains unchanged. 
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static uariable: a variable that Is allocated before execution of the 
program begins and that remains allocated for the duration of execution of 
the program. 

variable 

(1) in computer programming, a character or group of characters that 
refers to a value and, in the execution of a computer program, 
corresponds to an address. 

(2) a quantity which can assume any of a given set of values 

Three more terms need to be defined: A bound ydriobJe is one of a 

function's formal parameters [function's argumentsl. A gfobdl yonab/e has 
its value set at the top level. A free yanable is not a bound variable, but its 
value is used or changed by a function. (Wilensky, 1984, pp. 39-40) Now that 
the terms have been defined, the concept of variable scoping can be 
examined. 

There are two basic variable scoping techniques static scoping 
and dynamic scoping. In static scoping (also called lexical scoping) a 
procedure is called in the environment of its definition; in dynamic scoping 
a procedure is called in the environment of its caller. '* (MaCLennan, pp. 1 12- 
1 13, 1983). In other words, (nacLennan, p. 109, 1983); 

• In dynamic scoping the meanings of statements and expressions are 
determined by the dynamic structure of the computations evolving in time. 

• In static scoping the meanings of statements and expressions are 
determined by the static structure of the program. 

Franz LISP is a dynamically scoped language."^ Therefore, bound 
variables which are changed during a function call are restored to their 
original values upon exiting the function. If calls to other functions are 



7 COMMON LISP is a lexically scoped language (Winston, 1984, p. 54). 
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called function. However, changes to a free variable are not restored. If the 
free variable has the same name as a global variable, then other instances 
of the global variable will also change! (Wilensky, 1984, pp. 40-41)(Winston, 
1984, pp. 54-55)(MacLennan, 1983, pp. 284-288) 

An additional consideration, besides variable scoping, is the method 
used to pass parameters to a function. This is done in either of two ways; 
cdJI by vdJue or CdU by reference. LISP uses cal/ by value. 

To explain the difference in the two methods, recall that functions 
have a list of arguments (formal parameters or dummy variablesl. These 
arguments correspond to a list of actual parameters when the function is 
applied. In other words, the arguments are bound to the actual parameters. 
In most programming languages the user can assign values to symbols and 
these symbols can be used as actual parameters in a function. The issue now 
becomes one of passing the symbol's value or address. In can by reference 
the address of the actual parameter is bound to the argument. Ca// by value 
only copies the actual parameter's value: control over the actual parameter's 
value is not handed over. (MacLennan, 1983, pp. 53-58) 

The difference in the two methods can be seen by examining the 
effect of using a free variable, “free", whose value has been set at 2 
(Winston, 1984, p. 55): 

-> (setq3 free 2)<CR> 

;; The global variable "free" is set to a value of 2, e.g., 

;; free ;= 2 

2 



® See Section II.C.3.a for methods of binding symbols in LISP. 
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-> (defuD^ test (bound) 

(setq bound (1+ bound)) 

;; bound ;= bound + 1 

;; The symbol “free' is not bound within the context of test. 

(« bound free))<CR> 

;; the result := bound + free 

test 

-> (test free)<CR> 

;; First, “bound* assumes “free’s" value: bound := free’s value := 2 
;; Second, bound := bound ♦ 1 := 2 + 1 := 3 
;; Third, the result := bound + free := 3 +2 =5 

5 

In contrast if LISP used caJJ by reference. : 

(1) bound ;:= free := 2 

(2) “bound" increments: bound := bound + 1 := 1 + 2 = 3 

(3) since bound ::= free, "free" also becomes 3: free := 3 

(4) the result is: bound + free := 3 + 3 = 6 

In summary, Franz Lisp resolves the problems of variable context and 
scoping by using call by value and dynamic scoping. This issue can be 
extended to functions. Next, consider how functions refer to other functions 
or to themselves. 

5. Recursion and Iteration 

LISP allows functions to refer to themselves. This approach, known as 
recursion, is briefly introduced in this section.^o Suppose a function that 
raises a given integer base to a nonnegative integer power is desired. Two 



9 iefoB is an alternate method of defining functions, see Section II.C.2. 
A more in depth discussion of recursion is given in Section II.C.4. 
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possible algorithmic approaches are: 

(1) Iterative: 

(a) Set the result to 1; 

(b) set the index to the power; 

(c) iterate, by multiplying the result with the base and reducing 
the index by 1; and, 

(d) stop when the index reaches zero. 

The iterative algorithm divides up an operation into increments which 
are repeated a specified number of times. In recursion, a function calls 
itself until a basis condition is reached. The key to writing recursive 
functions is to ensure the basis condition is well formulated, for example: 

(2) Recursive: 

(a) ‘If the power is zero give a result of 1. [BASIS] Otherwise, 

(b) multiply the base with the result of applying this algorithm 
to the original base and the power reduced by one. [RECURSION] 

In an imperative language iteration is commonly used, whereas in an 
applicative language recursion often seems more natural (Gray, 1984, p. 51). 
The above example shows how an iterative problem can be stated 
recursively. But, although iteration and recursion are theoretically 
equivalent, it’s not always trivial to convert from one to the other. 
(MacLennan, 1983, p. 394) 

More will be said about iteration and recursion in Section II.C, in the 
meantime, a discussion of how Franz Lisp is used is now presented. 
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B. im-ERPRETED, COMPILED OR DUMPED LISP 
The Interpreter allows interactive running of LISP programs and provides 
an effective environment for debugging LISP code. At the same time, LISP 
also provides a compiler which can considerably speed up program execution 
for large code segments. This section examines the different ways LISP can 
be run and covers very basic Input and output. 

1. The LISP Read-Eval-Print Loop: Interpreted LISP 
In Section II.A.1, several examples showed how the LISP Interpreter 
“reads" and "evaluates" Input, and then "prints" out a result. This read-eval- 
print loop Is discussed In this section. The two major participants In this 
cycle, eeal and qaote, are also covered. 

■ a. The LISP Prompt " -> " , Start " ( " and Stop " ) " 

To obtain " -> ", so that <LISP form>s with " ( " and " ) " can run, 
the Franz Lisp Interpreter is invoked by typing lisp after the UNIX^ prompt: 

X lisp<CR> 

Franz Lisp Opas 38.69 

-> 

The ‘ " Is a prompt sign which means that inputs will be 

"evaluated" or "Interpreted*. An open parenthesis, " ( ", instructs the 
Interpreter to do whatever follows, and a closed parenthesis, " ) ", tells the 
Interpreter to stop doing it. (Wilensky, 1984, p. 2)(Hasemer, 1984, p. 6) 
Therefore, If the user Inputs: (pins 12 3) <CR>, the " ( " starts the LISP 
Interpreter "plusing" 1 with 2, then with 3, and stops "plusing" upon 
reaching " ) ". For example: 

-> (pins 1 2 3) <CR> 

6 
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This cycle of reading inputs, evaluating them and returning a result 
is referred to as the LISP read-eval-prlnt loop. (Hasemer, 1984, p.4) But 
what does It mean to say that the Interpreter "evaluates" <LISP form>s? The 
next section answers this question by describing the function used by the 
LISP system to obtain the results of a <LISP form> Input after the prompt 
sign. 

b, A Universal LISP Function: 

When the interpreter "reads" input, it is applying a function, esal, 
which can Interpret all LISP functions. The evaluation function's syntax Is 
illustrated below: 

<value> ::= -> (aval <LISP form>) 

<value> ::= <LISP form> 

The eoal function operates as follows (Winston, 1984, p 34): 

(1) If the form is a <number>: return the <number>. Otherwise, 

(2) If the form is a <symbol>: return its <value>. Otherwise. 

(3) If there is a <specla1 symbob: it's an exception. Otherwise, 

(4) Apply eval to the <llst>'s tai 1,^2 then 

(5) Apply the <llst>'s head to the <llst>'s evaluated tall. 

Eval assumes the hierarchy of LISP objects (Winston, 1984, p.21) 
shown in Figure 2.3 below: 



’'When John McCarthy was developing LISP he proved that there is a 
universal LISP function, eval, which can interpret any LISP function. This is 
similar to the universal Turing machine that can simulate any other Turing 
machine. (Chamiak, 1985, p. 48)(MacLennan, 1983, p. 343) 

*2 Refer to Sections II.A.2, II.C.1 and II.C.3.b. 
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<LISP fomn>si3 or 
<express1on>s 
/ \ 

<alom>s <list>s 

/ \ 

<number>s <symbol>s 
/ \ 

<floaling-point> dntegens 

Figure 2.2 The LISP Object Hierarchy 
Examples of these LISP objects are shown in Table 2.1: 

TABLE 2.1 

EXAMPLES OF LISP OBJECTS 
Example LISP Code 

(plas 1 2), 1.23, (♦ (plus 1 2) 3), 

0, (Uq oiHe) 1 2)), (plus 1 2), 

1, 1.1, fl, iDomuo, . . . 
a, mau, uio223, TLTLerr, . . . 

... . t . . . ... - ~ 

f ' / 9 f 3 f 3^ • • • 

It seems that LISP is always searching for a value. The next 
section answers the question: "How does it accept something literally?" 
c. Eval's dual: quate or " ‘ " 

When evaluation is undesirable it is inhibited with quote or its 
abbreviated form, a quote mark. The " * " is a <spec1al symbob that stops 
evaluation. This idea is evident from the syntax: 

<LISP form> ::= -> ((quote <LISP form>) I *<LISP form>}<CR> 



LISP Objects 

• <LISP form>s 

• <list>s 

• <atom>s 

• <symbol>s 

• <special symbobs 



13 Refer to Sections II.A.2, II.A.3 and ll.C. 1. 

1^ "\" (backslash! is an escape character. " and " " are described in 

Section III.A.1.2 
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A few examples illustrate the effect of qa«te or ‘ 

-> (qaste (a !i|)<CR> 

" (quote <LISP form>) 

(a b) 

-> *(a b)<CR> 

(a b) 

-> (a bl<CR> 

;; If *(a b)‘ is input without first defining *a‘ as a function, then 
;; an error results. The error is cleared using the reset function. 

Erron aval: OBdefiaed faectiaa a 
<l>: (reset)<CR> 

Two examples now show how the quote mark Is used and the error 
that results when a variable Is evaluated without having been given a value: 

-> 'aastralaatbropas<CR> 
aastralaatbrapas 

-> a<CR> 

Erran Badefiaed aariable: a 

< 1 >: 

The variable ’a" doesn't have a value; therefore, the LISP system 

complains with an error message, leaves the standanJ read-eval-print loop 

and enters a debugging loop. The * <1>: * Is the LISP error prompt. The user 

can continue typing expressions. Or, to remove the error, simply reset the 

system as follows (Wllensky, 1984, p.6): 

<1>: (reset)<CR> 

[Retara ta top looell 
-> 
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However, there are errors where execution might not be stopped by 
the interpreter^^, in that case, lisp can be stopped with an interrupt. The 
first control C I "'C ] sets an interrupt flag: the system waits for a "safe" 
place to exit. The second ''C forces all system calls to compiled code to 
check the interrupt flag; and finally, a third "‘C causes an immediate 
interrupt. (Foderado, 1983, Section 10.6) Here is an example: 

''c '‘e ''c 

Break ail 

<1>: 

An interpreter is a useful interactive tool; however, to handle 
large programs and obtain efficient object code, a compiler is needed. 

2. Compiled LISP 

Compilation of LISP programs increases their execution speed. In 
order to keep compilation dependencies among several programs 
straightened out, a makefile is used. In addition, a makefile can join 
together several programs so they can run as a large unit, 
a. The Compiler 

The Franz Lisp compiler is invoked from the UNIX® C-Shell with 
the following command (Foderado, 1983, Chapter 12): 

% liszt I“<option>*l <fi1ename> 

There are several options, among which, f [compile in quiet model 
and ■ [create a cross reference file) are very useful. The compiler can be run 
with several options at one time as follows: 

’5 Richard Hamming has jokingly said that perhaps computers do in fact 
show free will, it's just that people always call a repairman when they do 
it. 
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X liszt -qa liBcala.r^<CR> 

This command will create a lincoln.o {object code filel and 
lincoln.x [cross reference filel. To use the cross reference file, it must be 
filtered through the program Ixref: 

X laref liacola.a > liDcalB-a-ref<CR> 

The “ > ■ is used in UNIX® to redirect output, in this case, the 
human readable cross reference file is placed in lincoln-x-ref. This file will 
show all the functions in lincoln and where they are used. 

If functions from one program are used in another, this can then 
present a problem during compilation. How can these interrelationships be 
effectively managed? A makefile is the answer, 
b. Compilation Dependencies: Makefile 

Large programs such as LBS or MacPitts are subdivided into 

functional parts; however, between these subprograms there exist 

dependencies. For example, lincoln.l contains primitive functions used by 

L5.1 [the layout language] and L5.1 is in turn used to describe basic circuit 

layouts in organelles.l [functional units]. If there are twenty subprograms 

each with dependencies, then making changes can become a major chore. 

UNIX® has a utility to ease this difficulty: makefile. A makefile consists of 

dependencies, prerequisites and actions with this syntax: 

<makefile> ::= {<dependent result> : <prerequisite result>* 

<action>}'*’ 



linconl.l is a file containing many useful lisp functions used at MIT 
Lincoln Laboratories, see Chapter III. 
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Consider the following example makefile composed of four 
dependent results (L5.o, morK, clean, and doc). The desired results are 
separated by a colon from their prerequisites and placed on the same line. 
Notice that two results, clean, and doc, have no associated prerequisites. 
The next line contains the actions to create each result. Assume that all of 
this code Is in a file named ‘ Makefile ' In the user's directory which 
contains L5.1 and Hncoln.l. Makefile's contents are now presented, and 

3 

described Immediately afterwards Ithe explanation continues into Section 
11.B.3; 

LS.o: LS.I lincoln.a 
liszt -qn LS 

npork: LS.a lincoln.a 

echo^'^ *(enal-HPiien (enaON^^ 

(load 'liacoln.a)(load 'L5.o)\ 

(domplisp^^ »ork)(enit))* I lisp 

clean: na^ -f LS.o lincoln.o 



The echo command prints out Its arguments. The function, enal- 
»lien, tells the LISP compiler to evaluate the expressions that follow. 
Instead of compiling them. (Wilensky, 1983, 281) 

>8 The backslash " \ ' Is an escape character, therefore the next line Is 
treated as a continuation. The ' I " stands for "pipe", I.e., the results of the 
first process are passed on to the next process. 

19 Saves the LISP environment in an executable file named "work". Typing 
"work" will then recreate the LISP system as It was running when it was 
dumped. 

20 Forced removal of files. 



35 



doc: 

echo ■ print LS.I lincoln.l Makefile ‘ I csn 

This makefile can compile L5.1, and ensure that the dependent files are 
updated before doing it, by using the UNIX® make command: 

X make L5.o<CR> 

* The <prerequisite result> is lincoln.o, so this is created first: 

/nsr/acb/liszt -qii lincoln 

* The liszt compiler takes the lincoln source file and compiles 

* it; however, there are several warnings that can be ignored. 

XlDaming: lincaln.l : rotate : . . . 

* Now that all the prerequisites are complete, L5.o is compiled. 

X/usr/acb/liszt -qn L5 

* When everything is done the UNIX® system is restored. 

X 

In a similar fashion to print out the makefile and source code files: 

X make doc<CR> 

♦21 Pipe the print organelles.l etc. command to the UNIX® shell. 

* This causes these files to be printed out. 

echo * LS.I lincoln.l Makefile* I csh 

* Notice that the <action>s are printed out. In this case the user 

* would go to the line printer and print up copies of these files. 
X 

Or, perhaps, to remove undesired object code files and list the files. 

X make clean<CR> 

* Remove files ending in *.o“ or ”.x“ and then list the directory 

* contents on the terminal. 

rm -f *.0 
nn -f ♦.« 

Is 

* The ”.o‘ and ”.x“ files are removed and a directory listing given; 

DIR RERD_ME_FIRST chip.l 



21 The UNIX® shell ignores anything after ‘ ♦ “, therefore this symbol is 
used to insert comments. 
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Eaamples 

INSTALL 

L5.I 



arrag.l 

bio 

c-raatines.c 



top.l 

eatract.l 

siin.l 



Makefile 

* And finally, back to the UNIX® prompt. 

X 

LISP files which are dependent on each other can be organized using 
a makefile. They can also be individually loaded into the interpreter and 
saved as one executable file using danplisp. 

3. Interpreted and Comoiled LISP: damolisa 

In some programming languages disparate programs can be combined 
to form a working unit using a linker. In LISP this can be achieved by 
creating an 'environment' that contains all the programs. This is what the 
work; section of the example makefile created in the previous section does; 

X make mark<CR> 

* Execute the actions under the 'work' heading of this makefile. 

ecbo ‘Ceual-uiben (euallCload ‘liacolo.oNload *L5.a) 
(damplisp markHeiiit))* I lisp 

* Load lincoln.o, L5.o and organelles.o into LISP, dump this envi- 

^ronment in an executable file named ’work" and then exit LISP. 

Fraaz Lisp, Opus 38.69 

-> [fasi lincoln.o] 

;; fasl is the function LISP uses to load object code files. 

-> [fasl LS.a] 

X 

In summmary, an executable file, mark, has been created. Typing 
mark as an imperative command places the user in LISP with the functions 
in L5 and lincoln also available. 



X marfc<CR> 
-> 
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This is a LISP environment that contains lincoln and L5. If the user 
wants to load another file into this environment the load22 function can be 
used: 



-> (load 'defstnicts.o)<CR> 

;; (load '<f11ename>) 

;; The function LISP uses to load object code is fasl. 

IfasI defstracts.o] 
t 

-> (load 'top.l)<CR> 

;; Source code can also be loaded mto the interpreter. 

[load top.l] 
t 

To save all these changes in the LISP environment: 

-> (dumplisp ‘temporarg)<CR> 

;; Dumping LISP into "work" will result in an error since work is 
;; the process that's running LISP. 

oil 

To leave LISP and return to UNIX® : 

-> (eait)<CR> 

X mu temporary iuorlc<CR> 

* "mv" moves the file "temporary" into the file "work". 

Another approach for creating a LISP environment is to use a .lisprc 
file. The LISP interpreter always checks the user's directory to see if a 
lisprc file with instructions exists. An example .lisprc file that loads 
lincoln.o, L5.o and organelles.o into LISP is; 



22 The function ioclode also places files into LISP. Unlike load, it does 
not evaluate its argument.lFoderado, 1983, p. 6-4 llWilensky, 1984, p. 282) 
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X cat .llsprc<CR> 

^ Tne UNIX© ‘car command dumps the file ’.llsprc' onto the 

* terminal screen. 

(eval-mhen (load eoal) 

(load ’lincoln.o) 

(lead ’L5.o) 

(load *organelles.o) ) 

Since LISP automatically loads the .lisprc file [in this case all that 
the file contains is one large ooal-iDlieB <LISP form>l, then the result is 
that all three load functions are evaluated and the files loaded in. 

X lisp<CR> 

* The lisp interpreter is invoked and the .lisprc file is loaded. 

Franz Lisp Opas 38.69 

-> 

The user is now in LISP with the three files loaded. The main 
difference between using this method and dumplisp is that a dumped file 
usually requires at least a megabyte of storage, whereas loading several 
files using the .lisprc file takes a short while.23 in Chapter V.A and Appendix 
A.B it will be seen that the MacPitts and LBS environments can be invoked by 
typing their respective names without any arguments. For example: 

X macpitts [or lbs] 

osage: macpitts <filenarae> I<options>] 

-> 

A closer look is now taken at how files are input into LISP and how 
functions can be output into files. 



23 A compromise between these two approaches Is to use the autorun 
option when compiling a LISP file [e.g., X liszt -r <filename>]. This creates 
an object file which has a small piece of bootstrap code attached. The 
object file can then be run as an executable file. (Wilensky, 1984, p. 284) 
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4. Basic Input and Output M/O l 

Large programs are usually stored in files and loaded into LISP using 
load.24They can be edited using the vi editor by calling the LISP functions 

Hi or uil; 

-> (Di25 top.l)<CR> 

Places the user in VI editing the file top.l and when the user 
;; finishes returns back to LISP. 

t 

-> (oil organeilcs.l)<CR> 

;; Places organelles. 1 into VI and when editing is complete, loads 
;; organelles.l into LISP and returns nil. 

[load organelles. 1] 
nil 

Functions that have been created in the interpreter can be output into 
a file using the pretty print, pp, function. (Foderado, 1983, Chapter 5) 
(Wilensky, 1984, pp 134-137) Part of this function’s syntax is shown below: 
<LISP form> ;;= 

-> (pp (CF <fi1e-name>)] {<function-name> I <symbol>})<CR> 
For example, to pretty print out the m-tn-tlie-n function: 

-> (pp in-to-tlie-n)<CR> 

;; Output the function m-to-the-n to the screen. 

(def m-to-tbe-n 
(lambda (m n) 

(cond ((zerop n) 1) 

(t (times m (m-to-tbe-n m (1- a)))) ) ) ) 



24 See the previous discussion on interpreted LISP. 

25 The MacPitts version of L5 has a vi function defined in it. However, it 
automatically loads the file into LISP. 
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The pretty print function can also be used to send <LI5P form>s to a 
file in the following fashion: 

-> (pp 26 (F temp.n m-to-the-n)<CR> 

;; Output the function m-to-the-n to the file temp.1. 

t 

Conversely, a <LISP form> can be read from a file, without being 
evaluated, using read: 

-> (read (infile 'temp.O)<CR> 

;; Read the next <LISP form> from the temp.l file. When the end of 
;; file is reached then nil is returned. The <L1SP form> is not 
;; evaluated when read. To do so eval must be explicitly used. For 
;; example; (eval (read (infile '4-flags))), where 4-flags has a 
;; <LISP form> that needs to be evaluated. 

(def m-to-tlie-n 
(lambda (m n) 

(cond ((zerop n) I) 

(t (times m (m-to-the-n m (1- n)))) ) ) ) 



-> (enit)<CR> 

;; Leave LISP and then output temp.l to the screen using cat 



26 Other functions that are used for output are patom and print. Their 
syntax is similar 

<L1SP form> ::= 

-> (patom I')<LISP form> [(outfile <filename> [■a])l)<CR> 
<L1SP form>::= 

-> (print [']<LISP form> [(ontfile <filename> (*o])l)<CR> 
These functions both output to the terminal if the optional outfile 
argument is not given [the *a appends the output to the previous file 
contents, otherwise they are wiped out]. Because these functions do not 
send carriage returns when they finish their output, they are usually seen in 
conjunction with (terpri [(outfile <filename> ['aj) which outputs a 
terminate line character sequence. For example: 

-> (patom *1 Stop printing. |)(terpri)<CR> 

Stop printing. 
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X cat temp.KCR> 

* The contents of temp.l are concatenated to the screen. 

(def m-to-thc-n 
(lambda (m n) 

(cond ((zerap n) 1) 

(t (times m (m-to-the-n m (1- a)))) ) ) ) 

Now, reentering LISP, the temp.l file is loaded into LISP and the 
function it contains is tested in the following sequence of events: 

X lisp<CR> 

;; Start the LISP environment. 

Franz Lisp, Opus 33.69 

-> (inclade terap.i)<CR> 

;; Load the temp.l file into which has the m-to-the-n function. 

[load temp.l] 
t 

-> (m-to-the-n 4 3)<CR> 

;; A test of the m-to-the-n function; 4^ := 64. 

64 

There are many other I/O functions In LISP, which give the user a 
great deal of control, hut these can be added to this basic set as the user’s 
needs grow. The next section presents a brief LISP lexicon and covers 
Iteration and recursion. 



C. LISP FUNCTIONS AND DATA 

Part of LISP'S power Is that it has the same format for data and 
functions; thereby, allowing functions to be manipulated as data. This idea 
is elaborated in this section along with an explanation of basic LISP 
primitives and control structures. These basic LISP constructs allow 
iterative or recursive algorithms to be easily implemented. 
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1. LISP'S Basic Structure: The List 



A runciion and a list or data look me same in LISP. For example, me 
next <LISP form>, 

(replace-item-poiots ioDerter neap-points). 

Is an application of a function [replace-itero-points] to Its arguments 
[innerter and neni-points]; or, it can also be a list of three elements 
[replace-item-points, innerter and neop-points]. 

Which one It It? It Is both! A LISP program Is a list, and eual 
normally applies the list’s head as a function to the list’s tall. If the list Is 
quoted, then It’s treated as data. (MacLennan, 1983, p. 348) 

Atoms and lists are referred to as symbolic ex'prsssions . Expressions 
are called forms If they are to be evaluated. ’Considered as data, a list may 
be called an expression; considered as a piece of procedure, the same list 
may be called a form’. (Winston, 1984, p. 20) 

With these Ideas In mind another look can be taken at the procedure 
for LISP function definition. 

2. LISP Function Definition: dcf and defon^ '^ 

Up to this point the reader has seen functions that take a fixed 
number of arguments all of which are evaluated. This class of functions Is 
called an Aipr. There are three other categories ; Jexpr and mocros’^. 
An fexpr takes an unlimited number of arguments, but does nt evaluate them. 



27 See Section II.A.2 for function definition using def. 

28 Macros are discussed In Chapter III. 
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The lexpr accepts a variaPle number of arguments and evaluates them. 
(Wilensky, pp. 116-122, 160-178) 

Two ways of creating expr's have been shown; def with a lambda 
function, or a lambda function by itself. There is another syntax for 
defining an expr [define fanctionl which, unlike def, doesn't use lambda 
notation; 

(defun <funct1on-name>(<argument>*) <LISP form>*) 

This function is applied in the same fashion as before; 

<value> ;;= -> (<function-namexparameter>*)<CR> 

Therefore, in summary, there are three ways of creating expr's; 

<expr> ;;= (lamlida (<argument>*)<LISP form>*) 

<expr> ;;= (def <function-name> 

(lambda (<argument>*)<LISP form>*)) 

<expr> ;;= (defun <function-name>(<argument>*) <LISP form>*) 

It is sometimes desirable to have a variable number of evaluated 
arguments in a function. There are several formats for lexpr's; 

<lexpr> :;= (defun <function-name> 

(<argument>* &optional^ <optional-argument>*) 
<LISP form>*) 

<lexpr> ;;= (defun <function-name><symbolxLISP form>*) 

<lexpr> ;;= (def <function-name> 

(lenpr (<symbol>) <LISP form>*)) 



See Section II.C.3.f for another example of the (^optional feature in 
the function matcb-tbat (Foderado, 1983, p. 4-4]. 
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For example, a function that finds the logarithm base 2 of a number 
can be denned in lisp as follows: 

-> (defan log-tiuo (numiier ^optional (Pase 2)) 

;; The primitive LISP function quotient finds the quotient of two 
;; numbers, and log finds the natural logarithm of a number. The 
;; optional argument “base” defaults to a value of 2 if a 
;; parameter Is not given for It. 

(quotient (log nunber)(log base)) )<CR> 

;; Find the logarithm base 2 or the given base of a number. 

log-tufo 

This function Is applied in the following ways: 

-> (log-tmo 13)<CR> 

;; (log-two <number>) 

;; Find the log base two (defaul] of 13. 

3.700439718141092 

-> (log-tioo 13 10)<CR> 

;; Evaluate the base ten log of 13. 

1.113943352306837 

Another way to define this lexpr is as follows: 

-> (defun log-tmo n 

;; In this format, the symbol “n“, will be bound with the number 
;; of arguments supplied. The function arg gives the parameter 
;; associated with the position corresponding to the number It is 
;; given. 

(quotient 

(log (arg 1)) 

;; If a second parameter Is provided use Us value. If not use 2. 

(log (cond 

((> n 1)(arg 2)) 

(t 2) ) ) ) )<CR> 
log-tmo 

The third functional class, an fexpr, doesn't evaluate Its arguments 
and takes a variable number of them. Nothing comes for free though, the 
flexibility of a variable number of Inputs Is offset by the overhead of 
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accessing the parameters. When parameters are Input to an fexpr they are 
all bundled up into a list which is bound to the fexpr s single argument. The 
parameters must be obtained from the list. 

There are two ways to create fexpr's; 

<fexpr> :;= Cdefun <funct1on-name> feupr 
(<argument>)<LlSP form>*) 

<fexpr> ;;= (def <function-name> 

(nlainbda (<argument>)<LlSP form>*)) 

A good example of an fexpr is a function that loads any number of 
files without having to quote the files (Wilenksky, 1984, p. 163): 

-> (defan load-files fenpr (files)(mapc 'load files))<CR> 

;; mapc is similar to mapcar^o in that it applies a function across 
;; one or more lists; however, it doesn’t return a useful value, i.e., 
;; the side-effect is what is desired in this case. 

load-files 

This function can load several files without having to quote them: 

-> (load-files lincoln.l L5.I)<CR> 

Hoad lincoln.ll 
(load L5.1] 

-> 

These three categories of LISP functions (expr, fexpr and lexpr) are 
found in different areas of MacPitts and LBS.^^ Some of these applications 
are examined in later chapters. However, it is useful at this juncture to look 
at LISP’S built-in functions 



^ See Section ll.C.3.e. 
See Chapter IV. 
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3. Frequentlu Used LISP Functions 

A synopsis of common LISP functions is presented to Drlefly 
familiarize the reader with LISP'S syntax. First, a look at functions used to 
give values to symbols. 

a. Binding Variables; set, setq, let and let* 

Variables are assigned values with set or setq [set quote]. 
Although set only takes one symbol at a time. It has a similar syntax to 

setq; 



(set {[•]<symbol>} {[‘1<LISP form>}) 

(setq {<symbol> [*]<LISP form>}+) 

These two functions are applied as follows; 

-> (set a *(a b c))<CR> 

;; Set "A" to have the value ‘(a b c)‘. 

(a b c) 

-> a<CR> 

;; A‘s value is (a b c). 

(a b c) 

-> (setq B a C (1 2 3) a (ulus I 2 3))<CR> 

;; The <symbobs are unevaluated, but are respectively assigned 
;; the results of evaluating the <LISP form>s. setq returns the 
;; value of the last evaluation it performs. 

;; B ;= A, C ;= ( 1 2 3) and D ;= (plus I 2 3) ;= 6 

6 

-> B<CR> 

;; B's value has been set to A, but A ;= (a b c). 

(a b c) 

-> C<CR> 

;; C's value is (1 2 3). 

(1 2 3) 
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-> D<CR> 

;; D's value is (plus 1 2 3) := 6 

6 

let and used to create an orderly environment in which 

to assign values to variables, apply functions to the variables and then 

restore the vanables to their original values. Their syntax is similar 

(let(*l ( {(<symbol> I']<LISP form>)}+)<LlSP form>*) 

So, assuming that A, B, C and D still have the above values 

assigned to them, an example that uses let is; 

-> (let ((a (times 2 3))(8 (plos 1 2 3 4))) (list B 3) )<CR> 
;; First, A and B are assigned values as follows; 

;; A := (times 2 3) := 6 and B ;= (plus 1 2 3 4);= 10 
;; Then, the remaining <LISP form> is evaluated as follows; 

;; (list A B) ;= (6 10) 

(6 10 ) 

-> B<CR> 

;; Variables are restored to their previous values; 

(o b c) 

let assigns values in parallel, let* does it serially; 

-> (let* 

;; First, set A = (+ 1 2 3) = 6 

((fl (plus 12 3)) 

;; Second, set B = (* A 5) = (* 6 5) = 30 

(B (times B 5)) 

;; Third, set C = (- B A) = (- 30 6) = 24 

(C (mines B B)) ) 

(list BBC) )<CR> 

;; The result is a list composed of A, B and C 

(6 30 24) 



iet\* might have to be used if the ‘ * ‘ is not being recognized by the 
interpreter or compiler. The ‘ \ ‘ serves as an ‘escape" cliaracter. 
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The variables are restored to the values they had prior to 
participating in the let* construct. With these methods of variable 
assignment in hand, a look is now taken at list manipulation, 
b. List Selection; car .cdr^^, nth , and nthcdr 
LISP is based on the application of functions to arguments. The 
syntax of LISP generally has a structure of the form; 
(<function-namexargument>*) 

Therefore, it seems natural to have a selector that picks the first 
element of a list, the "function", and another selector that returns all the 
elements of a list except the first, the "arguments". These selectors are car 

and cdr 

<head> ;;= -> (car <list>)<CR> 

<tail> ;:= -> (cdr <list>)<CR> 

<list> ;;= (<headxtail>)24 
<head> ::= <L1SP form> 

<tail> ;;= <LISP form> 

The application of these basic selector functions is shown below: 

-> (car (plus 1 2 3 4)) <CR> 

;; (car <list>) 

car selects the first {"function" or "head") list element 

plus 

The " tail" selector, cdr, is used as follows; 



33 car and cdr were assembly language instructions for the IBM 70^ on 
wnicn LISP was first implemented. An instruction was divided up into 
fields. Two of the fields were named the dd<Jress and decrameni . car and 
cdr were the instructions for getting the contents of the address pointed to 
by these fields. (Charniak, 1985, p.48) 

34 Compare to the definition of a list in Section II. A. 2. 
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-> (cdr '(plas 1 2 3 4))<CR> 

” (cdr <list>) 

;; cdr selects all elements except the first {“arguments" or “tail’} 
;; and returns them as a list 

(1 2 3 4) 

A more complicated example: 

-> (car (car (cdr (cdr ‘(pies I (times 2 3) 4 5)))))<CR> 

;; In order to simplify the notation, when car and cdr are applied 
;; in succession they are joined into one word, e g. 

;; (car (car (cdr (cdr x)))) would become (caaddr x) 

;; cdr ; (1 (times 2 3) 4 5) 

;; cddr : ((times 2 3) 4 5) 

;; caddr : (times 2 3) 

;; caaddr : times 
times 

The next illustration of these selectors uses as an abbreviated 

format; 

-> (cadadddr ‘(plus I (times 2 3) (minus (diuide 4 5) 5) 

7 8))<CR> 

;; cdr : ( 1 (times 2 3)(minus (divide 4 5) 6) 7 8) 
cddr ; ((times 2 3)(minus (divide 4 5) 6 ) 7 8) 

;; cdddr ; ((minus (divide 4 5) 6) 7 8) 

;; cadddr ; (minus (divide 4 5) 6) 

;; cdadddr : ((divide 4 5) 6) 

;; cadadddr : (divide 4 5) 

(diuide 4 5) 

There are two other useful list accessors: ntb and uthcdr They 

both have very similar syntax: 

(nth <number><list>) 

(ntbcdr <number><list>) 

They are practical alternatives to a succession of cars and cdrs, 
and are used in the following manner: 
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-> (oth 3 ‘(and in tbose days it came to pass))<CR> 

:: (nth <indexxlisl>) 

;; Starting at 0, return the indexed argument of the given list. 

dags 

->(nthcdr 2 '(hgiomorphisni: all is form & matter))<CR> 

;; (nthcdr <indexxlist>) 

;; Starting at 0, return the indexed cdr of the given list. 

(form matter) 

Lists can be separated into their components with the functions 

covered in this section; but, how are they built up? 

c. List Construction: cons, append and iist 

The list selectors car and cdr separate a list into its "head" or 

■function” and its “tail" or "arguments”. The list constructor cans is their 

dual: Tt synthesizes a "head” and "tail” into a list. (Winston, 1984, p. 29-31) 

<11st> ::= -> (cons l’]<head> l*l<tai1>)<CR> 

<list> ::= (<headxtail>) ::= -> (cons *<head> *<tail>)<CR> 

<head> ::= <L1SP form>, and <tail> ::= <list>35 

Therefore, in order to synthesize a list out of two parts: 

-> (cons 'pins *(12 3))<CR> 

;; (cons '<head> ’<tail>) 

(pins I 2 3) 

To create lists use list with this format: 

<list> ::= -> (list { (*]<L1SP form> }*)<CR> 

An example that makes a list out of several arguments is; 

-> (iist This 'is 'a ‘Joined *sentence!)<CR> 

;; Make a list out of the following elements. 

(This is a Joined sentence!) 



® In actuality an atom can form the tail element, this produces a dotted 
list, e.g., (<head>.<tail>) 
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In order to ‘splice* lists together use append; 

<11st> ;;= -> (append { •<11st> I (list CkLISP form>)}*)<CR> 

Both list and append evaluate their arguments, but append 
splices Its arguments' values together: 

-> (append '(IHis is) '(not a) '(disjoint sentence.))<CR> 

;; Join the lists into one list. 

(This is not a disjoint sentence.) 

The null list is called nil, this is also the LISP word for false^; 

-> (list ())<CR> 
nil 

List selectors and constructors break up or join LISP expressions 
and may be used to rearrange a list’s elements. These elements might be 
LISP functions or their arguments, that manipulated as data, can be placed 
into a list format in which the function can then be applied to its 
arguments. This idea is now examined. 

d. Functional Application: apply and fuocall 

These two functions apply a function to a list or to a set of 
arguments. The syntax for apply is; 

<value> :;= -> (apply <function-name> 

{(list (I')<parameter>}*) I '(<parameter>*)})<CR> 

apply takes a function and a list of parameters for the function 
as its arguments, as shown below: 

-> (apply 'plus '(I 2 3))<CR> 

;; (apply <function-namexparameter-list>) 

6 



^ See the discussion in Section ll.3.e. 
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-> (apply 'append '((a b)(c d)(e r)))<CR> 

(a b c d e f) 

fnncall is similar to apply, except that It accepts each parameter 
for the function individually. It has this format; 

<value> ::= -> (fancall <function-name> { I*]<parameter> }*)<CR> 
Examples of fnacall now follow; 

-> (fancall 'pins 1 2 3)<CR> 

;; (funcall <funct1on> { (‘]<parameter>}* ) 

6 

-> (funcall 'append '(a b) '(c d) *(e f))<CR> 

(a b c d e f) 

Up to this point, functions can be applied sequentially to each 
other; but so far, there is no way to conditionally apply a function. In order- 
to build control structures that can do this, the idea of a predicate is now 
introduced. 

e. Predicates (the Values t and nil) and the cond Control Structure 
A predicate is a function whose value is either true or false. The 
LISP symbol for true is t and for false it's nil. In LISP any non-nil value is 
considered to be true. Both t and nil evaluate to themselves. The empty list 
is also called nil and is the only LISP expression that is simultaneously a 
list and an atom! (Winston, 1984, p. 44-46) 

Therefore, the following is true: 

{ 1 1 nil } :;= -> (<predicatexLISP form>*)<CR> 

Many LISP predicates end with a p, e.g. Ilstp, rainnsp, etc., but 
there are important exceptions such as: atom, null and equal. (Touretzky, 
1 984, pp. 14-17) So, f or example: 
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-> (llstp ‘(a b c))<CR> 

j; Is “(a b c)“ a list? 

t 

-> (null *a)<CR> 

;; Is ■ a ‘ null? I.e., is It equal to nil. 

nil 

-> (atom 'a)<CR> 

;; Is * a “ an atom? 

t 

-> (equal nil '())<CR> 

;; Is nil equivalent to (). 

t 

->(>3 2 14 ) 

;; Some predicates accept more than one parameter. In this case, 

‘ checks to see if all the parameters are strictly decreasing. 

nil 

Predicates in conjunction with the conditional function, cond, are 

used to control execution flow. The conditional is similar to an ' IF . . ., THEN 

. . ., ELSEIF . . .‘ statement and has the following syntax; 

(cond ({<test form> <action>}-^)) 

<test form> ::= ( [not] <predicate form>) I 

( [and I or] {<predicate form> I <test>}*) 
<predicate form> ;;= (<predicatexLISP form>*) 

The <test>s are performed sequentially^? until one evaluates as t, 

then its corresponding action is performed. 

The LISP primitive functions and & or are simple control 

structures which are used as follows (Foderado, 1983, p. 4-1 & p. 4-13): 



^ nacPitts has a conditional form, cond, which conducts its tests in 
parallel, and selects the first one that's true. This mode of operation 
reflects the VLSI implementation of the conditional function in MacPitts. 
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-> (and)<CR> 

;; If “and" has no arguments it returns t. 

t 

-> (and I 2 (plus 2 3))<CR> 

;; If all its arguments are non-nil, then “and“ gives the value of 
;; its last argument; otherwise, if any argument evaluates to nil 
;; the result is nil. 

5 

-> (or)<CR> 

;; If "or" has no arguments it returns nil. 

nil 

-> (or (zerop^ !)(♦ 3 5)())<CR> 

;; Returns the first non-nil value, otherwise if all its 
;; arguments evaluate to nil, " or " returns nil. 

1 5 

In another example, examine how a predicate, meniber?,^^ is 
constructed using conditional tests and the LISP function mamiier; 

-> (member ‘a ‘(bead e))<CR> 

;; member returns a list that starts with the first instance 
;; of the element that is being checked for membership in a 
;; list. 

(a d e) 

The code for the member? predicate is now shown. Observe that 
“ list “ is a parameter and not the list function: 



38 -> (zerop 1 )<CR> 
nil 

-> (zerop 0)<CR> 
t 

38 See Chapter III for a description of lincoln.l. In lincoln.1 predicates 
usually end with a “ ? ". 
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-> (defun member? (element list) 

(cond 

;; IF the list is null, THEN return nil. 

;; This is the Basis Condition: it ensures termination. 

((null list ()) 

;; ELSEIF the element is equal to the head of the list, 

;; THEN return t 

((eq (car list) element) t) 

;; ELSEIF the element isn't equal to the list's head, THEN 
;; apply this procedure again to the list's tail. 

;; The t in this last conditional test means that if the 
;; other two conditional checks fail, then this last 
;; statement will always get done. 

;; This is the Recursive Condition; it ensures all the 
;; elements get checked for membership. 

( t (member? element (cdr list))) ))<CR> 
member? 

-> (member? 'and '(Self propbecg and recursion))<CR> 

;; (member? <elementxlist>) 

;; Is "and" a member of the list "Self prophecy and recursion"? 

t 

Another example of a function that uses the conditional statement 
follows. First, the function, matcb-tbat, is applied in a simple example; 

-> (raatch-that 3 '(1 2 3 4 5 6 7) '<)<CR> 

;; (match-that <element><listxpredicate>) 

;; Returns a list composed of elements in the list that satisfy the 
;; predicate relation with the thing. Notice that the optional 
;; argument was not used here. 

(4 5 6 7) 

Now the function's code is presented. Again note the use of the 
parameter" list ". The * tail " variable is were the results are being stored 
as the recursion unwinds; 



56 



-> (defuo match-that 

(thiag list predicate l^optlonal tail) 

(cond 

;; This is the recursion's basis condition; 

;; If the list is empty, then all the results are in the tail. 
;; Since the first elements are being consed into the tail 
;; first by the application of match-that to the remainder 
;; of the list, (cdr list), when the basis condition is met, 

;; all the element in the tail will be backwards. 

;; Therefore, reverse them and return this as the result. 

;; This is the Basis Condition; stop if the list is empty, 
((aali? list)(reDerse tail)) 

;; The list wasn't empty, therefore, apply the predicate 
;; to the element's head. If the predicate is satisfied, 

;; place the head in the list called "tail". 

;; This is a Recursive Condition: apply the predicate to 
;; first list element, (car list), and match-that to the 
;; rest of the list, (cdr list). 

((fancail predicate thing (car list)) 

(match-that 
thing 
(cdr list) 
predicate 

(cans (car list) tail)) ) 

;; Since the list wasn't empty and the head element did'nt 
" satisfy the predicate, apply this algorithm to the rest 
;; of the list. Another Recursive Condition. 

(t 

(match-that thing (cdr list) predicate taiiH^<CR> 
" LISP returns the function's name 

match-that 

Predicates can also be used in iterative control structures. 



^ The " 1 " is a right superparenthesis. A right superparenthesis can 
substitute for as many regular parenthesis, " ) " as would be required to 
close off the <LISP form>. However, the count stops as soon as a left 
superparenthesis, "I ", is encountered. (Wilensky, 1985, p. 42) 
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f. Iteration; prog, do, do*^^ and niapcar 
Although recursion Is very often used In LISP, there are times 
when an Iterative approach Is preferable. LISP has various Iterative control 
structure. One syntax for LISP Iteration uses prog (Wllensky, 1984, p. 77): 
(prog (<local-var1able>*) 

{ (setq <local-vanablexLISP form>) 1 <PR0G form> }*) 

<PR06 form> ;;= <tag> I (go <tag>) I 

(retain <LISP form>) 1 <LISP fonD> 

<tag> ;;= <atom> 

The use of prog Is like programming In BASIC with Its loops and 
go to’s. The way prog works Is as follows (Winston, 1984, p. 87): 

• The first position In a PROG Is always occupied by a list of parameters, 

which are all bound on entering the PROG. Each parameter that has a value 
before the PROG is evaluated Is restored to its previous value upon exit.lf 
there are no parameters, NIL or 0 must be In the first position. The 
parameters are each initialized to NIL automatically 

• The forms In the body of a PROG are evaluated one after the other. The 
values are Ignored, so the evaluations are only useful for side effects. If 
control runs off the end of a PROG, then NIL Is returned, just as with COND. 

• Whenever a RETURN expression is reached when evaluating a PROG, the 
PROG Is terminated Immediately. The value of the terminated PROG is 
thevalue of the argument in the RETURN expression that stopped the PROG, 
just as with DO. 

• Any top-level symbol in the body of a PROG is considered to be a position 
marker. These symbols, called tags , are not evaluated. They mark places 
to which control can be transferred by GO expressions. That Is, (GO <TAG>) 
transfers control to the form following the <TAG>. 



See the comment about let* and let\*. do and do* have the same 
relation as let and let*, do assigns values In parallel, whereas do* does It 
serially. 
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The setq's are used to assign values to variables within the context 
of the prog. As an example, review this definition of a factorial function; 

-> (defan factorial (integer) 

;; Bind local variables to nil. 

(prog (result) 

;; Initialize local variables 

(setq result 1) 

;; A loop that will find the factorial of a positive integer. 

loop 

;; IF the integer is zero then exit the prog and return the result. 

(cond ((zerop integer)(retarn result))) 

;; OTHERWISE, multiply the Integer by the accumulated result, 

;; then decrement the integer by one and repeat the loop. 

(setq result (* integer result)) 

(setq integer (1- integer))(go loop) ) )<CR> 
factorial 

A more structured iterative syntax, which can do everything prog 

does, uses do or do* (Winston, 1984, p. 86): 

(do ({(<variable> <initial-value> <update-form>)}*) 

( <end-test> <LISP form>* <result-form>) <body> )*^2 
<end-test> :;= <test form>'^3 

<result-form> ::= <LISP form>, and <body> ;;= <LISP form>* 

However, if an action is to be performed across lists, then “the 

lazy man's do loop", mapcar, can be used. (Winston, 1984, p. 79) For 

example, given the LISP primitive zerop, a list's elements can all be 

checked for equality with zero in one fell swoop: 

-> (mapcar 'zerop ’(1 0 a 0 0 2))<CR> 

(nil t nil t t nil) 



42 See Section II.C.4 for an example of do. 

43 See Section ll.C.3.e for <test form>'s format. 
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The mapcar function applies a function across the first list 
elements, then across the second list elements, until the shortest list is 
exhausted. The function must Pe able to take as many parameters as there 
are lists. Generalized lambda functions to perform complex operations can 
be constructed and applied across lists using mapcar. Its format is: 
(<va1ue>*) ::= -> (mapcar <function-name> { {'l<list>}*)<CR> 
Some examples of mapcar: 

-> (mapcar 'list '(a b c) ’(1 2 3) ’(9 7 Z))<CR> 

;; Make a list that has sublists with the respective element in 
;; each of the given lists. 

((a 1 U)(b 2 Y)(c 3 Z)} 

-> (mapcar '(lambda (h)(pIus » 5)) '(1 2 3 4 5))<CR> 

;; Add 5 to each list element. 

(6 7 8 9 10) 

-> (mapcar 

'(lambda (a y)(times » g)) 

'(I 2 3 4 5) '(3 4 5 67) )<CR> 

;; Multiply two lists. 

(3 8 15 24 35) 

LISP'S iterative control structures are convenient tools that 
supplement its naturally recursive style. 

4. Iteration and Recursion^ 

In an iterative routine, “indefinite repetition is designated by explicit 
instructions to do something repeatedly.” The do construct in LISP is one 
format for Iteration. (Wilensky, 1984, p. 75) An iteratively defined function 
which raises a number to a power is a good example (Winston, 1984, p. 85); 



Refer to the discussion in Section li.A. 
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-> (defoB Bi-to-the-n (m n) 

(do^^ ((result I (* m result)) 

(power n (- power 1))) 

((zerop power) resolt)))<CR> 

;; Raise a number to a positive power: m". 

m-to-the-n 

-> (m-to-the-B 2 3)<CR> 

;; result^ := 1, power := 3, (zerop 3) := nil 

;; result 2 := (* 2 0 := 2, power := (- 3 1) := 2 , (zerop 2) ;= nil 

;; results •= 2 2) := 4, power := (-2 1) := 1; (zerop 1) := nil 

;; result 4 :r (* 2 4) := 8, power := (- 1 1) := 0, (zerop 0) ;= t 

8 

Recursion accomplishes indefinite repetition 'by having a function call 
itself during its execution." (Wilensky, 1984, p. 73) A recursive 
implementation of oi-to-tbe-B (Winston, 1984, p. 64): 

-> (defuB Bi-to-the-B (m b) 

;; The exponent [ n ] should be a non-negative integer. 

(cood 

;; Test to see if the exponent [ n ] is zero, 

;; if it is, return a value of one. 

;; This is the Basis Condition. 

((zerop b) 1) 

;; if the exponent is not one. then 
;; multiply m by (m-to-the-n m (1- n)), n.b., 

;; the recursion will end since n will be reduced 
;; to zero and (m-to-the-n m 0) is one! 

;; This is the Recursive Condition. 

(t (♦ IB (m-to-the-B IB (1- b)'^^))) ) ) )<CR> 
iB-to-the-B 



Refer to Section II.C.3.e for do's syntax. 

1 - decrements by one, while 1 + increments by one. 
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-> (in-to-t&c-n 2 3)<CR> 

:: First time through; (m-to-the-n 2 3) 

;; m := 2, n := 3, (zerop 3) := nil, therefore 

;; result^ ;= (* 2 (m-to-the-n 2(1- 3))) := (* 2 (m-to-the-n 2 2)) 

;; Second time through: (m-to-the-n 2 2) 

;; m ;= 2, n := 2, (zerop 2) := nil, therefore 

;; result 2 := (* 2 (m-to-the-n 2(1- 2))) ;= (* 2 (m-to-the-n 2 D) 

;; Third time through: (m-to-the-n 2 1) 

;; m := 2, n := 1, (zerop 1) := nil, therefore 

;; resu 1 t 3 := (* 2 (m-to-the-n 2(1- 1))) := (* 2 (m-to-the-n 2 0)) 

;; Fourth time through; (m-to-the-n 2 p) 

;; m ;= 2, n := 0, (zerop 0) ;= t, therefore 

;; resu)t 4 •= ^ Finally a result! Now, substituting backwards: 

;; result3 := (* 2 result4) := (* 2 1) := 2 

;; result2 := (* 2 result3) := (* 2 2) ;= 4 

;; result^ := (* 2 result 2 ) ;= (* 2 4) ;= 8 

8 

LISP has a variety of useful control structures and a fecund 
vocabulary. In addition, LISP has other tools to aid in quickly developing 
working programs. Some of these are considered in the next section. 



D. THE FRANZ LISP PROGRAMMING ENVIRONMENT 

LISP has a rich panoply of tools to aid the programmer. Among these are 
a package for stepping through functions as they are being evaluated; a 
program for debugging faulty code; and, a facility for tracing functions and 
the values they are manipulating. 

1. Program Development Aids 

The stepper, debugger and tracer are normally automatically loaded 
into LISP when they are needed. They work based on a simple idea: it’s 
sometimes easier to see a mistake as a program is running than to catch a 
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logical error. The three basic functions associated with these programs are 

trace, debug and step.'^'^To see how they work, recall facfonal; 

-> (factoriai^ 5)<CR> 

;j 5M^3*2*1 := 120 

120 

The operation of zerop can be observed using trace, as follows; 

-> (trace zerop)<CR> 

[autoload /usr/lib/lisp/trace] 

[fasi /osr/lib/iisp/trace.o] 

;; The tracer returns a list of functions being traced. 

(zerop) 

Now, every time that zerop is used its associated values are shown; 

-> (factorial 5)<CR> 

1 <Enter> zerop (5) 

1 <EHIT> zerop nil 
1 <Enter> zerop (4) 

1 <E8I1> zerop nil 
1 <Enter> zerop (3) 

1 <EUI1> zerop nil 
1 <Enter> zerop (2) 

1 <EUIT> zerop nil 
1 <Enter> zerop (1) 

1 <EBIT> zerop nil 
1 <Enter> zerop (0) 

1 <EUIT> zerop t 
120 



For discussions of these areas see: 

(Foderado, 1983, Chapter 1 1 [Tracer], Chapter 14 [Stepper], 
ChapteriS [Debugger] and Chapter 16 [Editor]) 

(Wilensky, 1984, Chapter 11 [Debugging]) 

(Chamiak, 1985, Section 2.8 [Debugging]) 

(Winston, 1984, Chapter 14 [Debugging]) 

Defined in Section II.C.3.f. 
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ir the tracing feature Is no longer desired It can be stopped as 
follows: 

-> (untrace)<CR> 

;; The untrace function returns a list of all the functions 
;; it has stopped tracing. 

(zerop) 

Sometimes though, an error cannot be localized to any particular 
function. In that case the step function allows the user to observe the 
incremental operation of a program. The debugger can be entered from the 
stepper, or vice-versa, or it can be invoked separately. In this case the 
stepper is invoked so that only interpreted code is shown as follows: 

-> (step c)<CR> 

;; Step only interpreted code. If a "t" argument was 
;; provided then all code would be stepped. 

(autaload /asr/lib/lisp/step] 

[fast /usr/lib/lisp/slep.o] 
t 

-> (factorial 3)<CR> 

;; A <CR> is needed in order to continue stepping. A “q“ 

;; stops stepping. “p‘ shows the current form in full. An 
;; “n'<integer> steps through the given number of evalua- 
;; tions without stopping. A “d“ goes into the debugger. 

(factorial 3) 

3 

(prog (result) (setq result 1) loop (cond {9 &)) 

...) 

(setq result 1) 

1 

I 

(cond ((zerop integer) (return result)))<CR> 
(zerop Integer) 
integer = 3 
nil 
nil 

(setq result (* integer result))c<CR> 

3 
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(setq integer (ll-i integer))n2<CR> 

2 

(go loop) 

(cond ((zerop integer) (return result))) 
(zerop lnteger)d<CR> 

;; Go into debug mode. Usually invoked with: (debug) 

IfasI /nsr/lib/lisp/fiH.o] 

< debug > 

;; Obtain a listing of debug commands using help. 

: help<CR> 

u/un/uf/unf go up^ i.e. more recent 

(n frames) (of function f) 

up / up n go up to next (nth) non- 

system function 

d / dn go down, i.e. less recent 

(opposite of u and up) 

ok / go continue after an error or 

debug loop 

redo / redo f resume computation from 

current frame (or at fn f) 

step restart in single-step 

mode 

return e return from call with 

value of e (default is nil) 



edit 


edit the current stack 
frame 


editf / editf f 


edit nearest fn on stack 
(or edit fn f) 


top / bot 


go to top (bottom) of 
stack 


p / pp 


show current stack frame 
(pretty print) 


where 


give current stack posi- 
tion 


help / h / ? 


print this table — 
/usr/lisp/doc/fixit.ref 


help ... 


get the help for ... 


pop / "d 


exit one level of debug 
(reset) 
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bk / bK n / bk r backtrace (to nth frame) 

/ bk n f / (of fn f) 

..f function names only 

..a Include system functions 

..V show variable bindings 

..e show expressions in full 

..c go no deeper than here 

♦** combinations are allowed *** 

;; Find out where in the stack the user is at present. 
:i 0 here<CR> 

< debag > 

you are at top of stack, 
there are 1 debug’s beioni. 

;; Go down the stack. 

:dn<CR> 

;; This is the <LISP form> at this stack level: 

(eual (debug)) 

;; Go up to the stack top. 

:top<CR> 

< debug > 

:return 5<CR> 

;;The user intended to move down the stack and change 
;; the value being returned, but instead made a mistake, 

;; and therefore interrupted the action; 

Interrupt: 

Break nil 

;; Lisp will now go into an error loop and the stack 
;; contents saved up so the user can check them. The 
;; showstack function shows the current stack contents. 
;; The baktrace function is similar. Within debug 
;; baktrace is "bk". "bkfv" in debug would print out 
;; function names instead of <LISP forms> and would 
;; show variable bindings. 

<1>: (shoupstack)<CR> 

break-err-handl er 

♦break 

sgs:int-serv 

tyi 
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funcall-evalhook* 

evalhook* 

(zerop integer) 

(cand (<**> (retnrn result))) 
evaihook 

continue-evaluatlon 

funcall-evalhook* 

evaihook* 

Uond Uzerop integer) (return result))) 

(prog (result) (setq result 1) loop ...) 
evaihook 

continue-evaluatlon 

funcall-evalhook* 

evaihook* 

(prog (result) (setq result 1) loop ...) 

(factorial 3) 
evaihook 

continue-evaluatlon 

funcall-evalhook* 

evaihook* 

(factorial 3) 

;; The stack has LISP system function calls interspersed 
;; with the factorial function. A handy feature of the 
;; error loop is that the current variable values can be 
;; easily obtained. Showstack returns nil. 

nil 

;; What is the ’integer' variable’s value? 

<1>: integer<CR> 

2 

;; What is the "result" vanable's value? 

<1>: result<CR> 

3 

;; Leave the error loop. 

<1>: (reset)<CR> 

iRetom to top lenel] 

Hopefully, this very brief look at some LISP programming tools will 
encourage the user to experiment with them. The next section reviews the 
salient points covered up to now. 
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2. Summar u 

AUhouQh at first, ths fact that LISP functions and data look alike is 
disconcerting; after a brief period of adjustment, having onlyone fonriat for 
everything becomes a strong asset. Additionally, LISP is a mature language 
that has many program development tools integrated into it. 

A lot of other material was also covered in this chapter; however, 
LISP’S key ideas are well stated in this quote from (Brooks, 1985, p. 3). 



^ Mrt QC 
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• Lisp provides an interactive system in which the user ..uh' 
expression and Lisp it (or it) and prints out the 

result. Thus, large programs can be built and tested incrementally, and at 
each stage of testing the full power of Lisp is available to examine tne 
state of the program and data structures. Rather than go through anoiner 
edit-compile-link-run cycle to test a bug hypothesis, the user can test it 
directly by typing Lisp statements to the interpreter. 



• Lisp programs and data have the same form. An often-touted consequence 
of this is that Lisp programs can modify themselves. A more important 
result is that it is very simple to write embedded languages in Lisp. For a 
particular application, a user often can very quickly write a language (i e , 
a translator from the language into Lisp) that is in some way well suiieo 
to the problem being solved. 



» Lisp systems manage storage allocation for the user by providing a 
dynamic heap of storage that is allocated for data storage as needed, and 
then "garbage collected" (i.e. reclaimed) in a manner invisible to the user 
when no longer needed. The user is freed from worrying a prion about how 
much storage will be needed for a particular procedure over all possible 
inputs. 



• Most Lisp systems Include a compiler that compiles programs written in 
Lisp into efficient machine code. Thus, user programs can be run efficienly. 
In addition, a user-written embedded language can be compiled into 
machine code essentially for free; it need only translate user language 
programs into Lisp. 
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• Lisp functions (equivalent to subroutines or procedures in oUi 
languages) are data objects that can be passed as parameters to oth 
functions. This makes it possible to write extensible control structures in 
user programs that are very difficult to duplicate in more traditional 
languages. 



69 



a' a* 



III. MACROS. FUNCTIONS AND DATA STRUCTURES; LIMCQLN.L 



The program Ijncoln.l includes LISP macros and functions for numeric or 
string comparison, selection, and manipulation. In addition, lincoln.l 
contains a data structure macro, defstruct, which orders data by fields 
and creates macros to manage the data.i 

A. MACROS 

Macros are used "to write more readable code". (Wilensky, 1985, p. 180) 
They provide other advantages listed in this quote from Brooks, 1984, p. 195; 

• Macros provide a mechanism for writing program-writing programs. 

• Macros add an extra layer of interpretation to Lisp. In the interpreter, 
both layers get Isic] completed, one after the other. In the compiler, one 
layer gets [sic) done at compile time, and an assembly language program is 
produced to simulate the second layer at run time. 

• Macros provide an efficient mechanism for abstracting the structure of 
data out of a program. 

• Macros provide a mechanism for writing new special forms and control 
structures. 

Macros are used to extend LISP by using data abstraction. 



^The defstruct concept is similar to the "structural primitive" idea 
which some A1 researches naively hoped would lead through a process of 
generalization to a model of human conceptualization (Dreyfus, 1979, pp. 
166-9). 
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1. Data Abstraction and Macros 



Abstraction of low level functions can aid understanding. For 

example, the unmnemonic car might be renamed head: 

-> (defun head (u)(car h))<CR> 
head 

-> (head '(II B C D)|<CR> 

R 

The mnemonic quality of this new function is offset by the overhead 
of having a user defined function calling a LISP system function. The LISP 
function car takes one instruction, but a user defined function takes five or 
more instructions! (Brooks, 1984, pp. 179-180) 

Since data abstraction is an important programming tool, the cost of 
the extra function calls in compiled code is removed by the use of macros. 
"A macro is a function which accepts a Lisp expression as input and returns 
another Lisp expression." (Foderado, 1983, p. 8-3) 

A macro is efficient because it creates code that the LISP interpreter 
evaluates only once. Subsequent calls to the macro use the expanded code 
(Wilensky, 1984, pp. 180-195). The function defmacro (define macro] is 
one of three ways to create a macro (Foderado, 1983, p. 8-3). For example; 
<macro-name> ;;= 

-> (defmacro <macro-name> (<argument>*)<LISP form>*)<CR> 
<macro-name> :;= 

-> (def <macro-name> (macro (<argument>)<LISP form>*))<CR> 
<macro-name> ::= 

->(defun <macro-name> macro (<argument>)<LISP form>*)<CR> 
A macro is applied just like a function: 

<value> ::= -> (<macro-namexparameler>*)<CR> 
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These examples show that a macro acts very similary to a function; 

-> (defmacro head (H) (list 'car H))<CR> 

;; Define a macro that finds a list’s head. 

;; LISP returns the macro's name {recall the use of defun}. 

head 

-> (head (H B C 0))<CR> 

;; A macro is used like a function. 

R 

The LISP macroeapand primitive can be used to look at the code 
generated by the macro head: 

-> (macroeepand ‘(head *(fl B C 0)))<CR> 

;; The code that the macro "head” is expanded into is returned: 

(car (quote (BBC B))) 

, Therefore, after the initial macro expansion by the interpreter of 
(head R), all further calls refer to (car (quote H)). 

Macros never evaluate their arguments! That's why the macro is 
written in an awkward form using the list primitive: so that when the 
expression (list ‘car R) is passed to euol, the R argument will definitely 
be evaluated. (Winston, 1984, p. 124) 

2. Eval and The Backouote Macro^ ^^ 

LISP normally operates by applying euol to expressions, unless this is 
inhibited by quote. (Winston, 1984, pp. 34-35) The dual effect is created by 



2 Refer to the discussion in Sections ll.B. I.b & c of eual and quote. 

3 The backquote character macro is usually associated with " ‘ ", Because 
this backwards quote is difficult to distinguish from other diacritical 
marks, the " $ " is used in this thesis. This is done with: 

-> (eual-uilien (compile load eoalHsetsyntau ‘|$| ‘macro 
‘back-quote-ch-macro) ) 
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the backquote macro: expressions are not evaluated unless specified. 
(Foderado, 1983, pp. 8-3,8-4) The symbol for inhibiting evaluation is “ $ 
for evaluating " , " and for evaluating and splicing into a list ' ", 

(Wilensky, 1984, p. 202) These symbols can be applied in succession, as 
composite operators, and are summarized in Table 3.1 below: 

TABLE 3.1 



BACKQUOTE MACRO SYMBOLS 



Su mbol Function 



$ 



or ,$ 

,©$( ) or ,@*( ) 
$(,x) 

S(,x ,^y) 

$(,©x ,©y) 
$(,rx ,#*y) 



Inhibit one level of evaluation 
Evaluate (within the context of " $ "1 
Evaluate and append 
No-ops, they can be removed.'^ 

No-ops 
(list m) 

(cons H y) [y must be a list] 

(appeofl H y) (x & y must evaluate to lists] 
(append ‘n *y) [x and y must be lists] 



So for example, if the variable fl Is set to have as Its value the list 



(1 2 3), the effect of " $ and can be observed: 



-> (setq a *(1 2 3))<CR> 

;; The variable "A" Is assigned the list " (1 2 3) " as a value. 

(12 3) 



-> $(B ,R ,ea)<CR> 

" A " Is unevaluated, " ,A " Is evaluated, " ,@A " is evaluated and 
;; spliced into the list structure. 

(B (1 2 3) 1 2 3) 



4 -> $((a b) (C 0) ,©*(e f) ,®*(G H))<CR> 

;; ‘ “ acts as a composite operator: ,@(quote (<argument>)) 

;; So, first apply quote, and then " 

((a b) (C 0) e f 6 H) 
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Consider the following expression; 

-> (append 

(cons (list 'a *b) (cons (list 'C ‘D) '(e f ))) 

•(6 H) )<CR> 

;; The most deeply nested expressions are evaluated first; 

;; ’(e f) => (e f) 

;;(list ’C ’D) => (C D) 

;; (cons XC D)'(e f)) => ((C D) e f) 

;; (list 'a ’P) => (a b) 

;; (cons '(a b) ’((C D) e f)) => ((a b)(C D) e f) 

;; (append X(a b)(C D) e f) ’(G H)) => ((a b)(C D) e f G H) 

((a b) (C D) e f 6 H) 

The above LISP expression with append, cons and list is equivalent 



to; 

-> $((a b) (C 0) e f 6 H)<CR> 

;; The user can use the backquote character macro as a template. 

((a b) (C 0) e f 6 H) 

Here is how this result was obtained; 

(append (cons (list 'a ’b) (cons (list 'C ’D) ’(e f ))) '(G H)) 

;; substitute for the append; 

$(,@(cons (11st 'a 'd)(cons (list ’C 'D) Xe f))) ,@XG H)) 

;; substitute for the outermost cons; 

$(,@$( .(list 'a ’b) ,@(cons (list 'C ’D) Xe f))) ,@XG H)) 

;; substitute for the next cons; 

$(,<?$( ,$(a b) ,@$( .(list ‘C ’D) .@Xe f))) ,@XG H)) 

;; Eliminate no-ops 

$(,©$( .$(a b) .©$( ,$(C D) ,@Xe f)» ,@XG H) 

$((a b)(C D),@‘(e f),©‘(G H)) 

;; The desired "form"; 

$((a b)(C D) e f G H) 

The point of the above exercise is that the final result is much easier 
to scan than a series of lists, conses, and appends. The programmer can 
write code that looks like the desired result at the onset instead of 
manipulating a series of expressions as was done above. 
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The backquote macro is frequently used in writing macros. It's used to 
create a template of the code the macro will provide to eual, for example; 

-> (defmacro head (H) $(car ,H))<CR> 

;; Equivalent to; (defmacro head (XKlist ‘car X)) 

head 

These ideas are all brought to fruition when functions that generate 
other functions are made. A good example is the defstruct (define 
structure] macro.s This macro consists of two levels. The lowest level 
creates the desired function according to a template. The upper level 
evaluates the function that was created. A brief sketch and a bit of the LISP 
code demonstrates the idea:^ 

eval 

* -■ I 

defstruct 
/ \ 
eval eval 

/ \ 

defstruct-short defstruct-long 
Figure 3.1 The Defstruct Function Hierarchy 
The code that follows reflects the structure in Figure 3.1. There is a 
main eval-uihen form that evaluates the defstruct function. This 
function in turn has two eval-when forms in it. They will either evaluate 



5 See Section III.C for more detail on defstruct. 

6 The reader should skim through this code looking at how the evaluation 
statements are nested with macro or function definitions. Look at the code's 
form and the extent that it “shows'’ the macros it is generating.. The LISP 
function eval-when tells the interpreter or compiler to evaluate this code 
when it is loaded into LISP. 
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the results of a defstruct-short or a defstruct-long function. The 
reader should keep in mind that the results of these functions are in turn 
other functions. Here is the LISP code: 

-> (eual-uilien (compile load eual) 

;;Evaluate whatever destruct returns: 

(def defstruct (macro (body) 

(cond 

(distp (caddr body)) 

;; Conditionally evaluate the result of defstruct-short: 

$(eual-iuhen (compile load eoal) 
,@(defstruct-short (cadr body) 

(caddr body)))) 

;; Conditionally evaluate the result of defstruct-long: 

(t $(eual-uihen (compile load eual) 
,e(defstruct-lony (cadr body) 

(cddr body))))))) 

(defun defstruct-short (type fields) 

;;The defstruct-short function makes "short" structure macros: 

$((def ,(concat 'moke- type) 

(macro (») $$(„@(cdr »)))) 
,@(defstruct-short-fields type fields I) 
,@(defstruct-replace-fields type fields I))) 
(defun defstruct-Iony (type body) 

;;The defstruct-long function makes "long" structure macros: 
(cond 

((null body)0) 

((or (null (cdr body))(listp (car body) 

(atom? (cadr body))) 

(error 'I Inualid defstruct syntau in 

defstruct-long i)) 

(t 

$(,(make-case-type (car body) type) 
,(is-type-case? type (car body)) 
,9(defstruct-long-fields type 

(car body)(cadr body) 2) 
,@(defstruct-replace-fields 

(concat (car body) '- type)(cadr body) 2) 
,@(defstruct-long type (cddr body))))))<CR> 
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As an example, a list with fields "name” and "age” will be called a 
"man”. Examining the results from the bottom up shows how functions are 
first created and then evaluated into the LISP environment. First the lowest 
level functions defstruct-short-fields and defstnict-replace- 
fieids create macro definitions in the following fashion; 

-> (defstruct-short-fields 'man '(name age) 1)<CR> 

;; Since there are two fields two selector macro definitions 
;; are made. They are returned in a list.The results are: 

;; A macro definition that selects the name field: man-name. 

((def man-name (macro (bodg)$(car ,(cadr bodg)))) 

;; A macro definition that selects the age field; man-age. 

(def man-age (macro (bodg)$(cadr ,(cadr body))))) 

-> (defstruct-replace-fields 'man '(name age) 1)<CR> 

;; Since there are two fields two mutator macro definitions 
j; are made. They are returned in a list. 

;; A macro definition that replaces the name field with a new 
;; value is created and called replace-man-name. 

((def replace-man-name (macro (bodg)$(append 
(list ,(caddr body))(cdr ,(cadr body))))) 

;; A macro definition that replaces the age field with a new 
j; value is created and named replace-man-age. 

(def replace-man-age (macro (body)$(append 
(list (car ,(cadr bodg)),(caddr body)) 

(cddr ,(cadr body))))) ) 



The above results are now spliced into a list of macros: 

-> (defstruct-short ‘man '(name age))<CR> 

;; The macro definitions are spliced into a list: 

((def make-man (macro (body) ... ) 

(def man-name (macro (body) ... ) 

(def man-age (macro (bodg) ... ) 

(def repiace-man-name (macro (body) ... ) 
(def replace-man-age (macro (bodg) ... ) ) 
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The list of macros is evaluated, notice that this is equivalent to using 
the defstruct function as follows; 

-> (defstruct 'man '(name age))<CR> 

;; Only the name of the last macro evaluated is returned; 

replace-man-age 

The macros can now be used like any other LISP function: 

-> (replace-man-name '(jim 23) 'mike)<CR> 

;; Replace the name field of this "man" structure with "mike". 

(mike 23) 

-> (man-age '(mike 23))<CR> 

;; Select the "age" field of this "man" structure. 

23 

The selector and mutator function interactions with the "man's" "age" 
and "name" are represented in the following figure. An arrow into the field 
shows that data is being “deposited" and similarly an arrow from a field 
represents data that is being "extracted". 

man 
/ \ 

/ \ 

replace-man-age --> age name <-- replace-man-name 

I I 

.V V 

man-age man-name 

Figure 3.2 "Man" Defstruct Operator Functions 

This example, although a bit involved, has shown how LISP macros can 
be used to create other functions. However, before moving on to the next 
section, the unconvinced reader should glance at Figure 3.3 and compare it 
to the definition of defstruct-long that used backquote a few pages ago. 

There are many handy macros in lincoln.l. These are now examined. 
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(def defstruct-*long 
(lomlida (type body) 

(cond ((null body) ()) 

((or (null (cdr body)) 

(list? (car body)) 

(atom? (cadr body))) 

(err 'llnualid defstruct syntauD) 

(t (append (cons (list 'def 

(concat 'make-* (car body) type) 
(list 'macro 
'(body) 

(list 'cons 
"list 

(list 'cons 
(list 'list 
"quote 
(list 'quote 

(car body))) 

'(cdr body))))) 

(cons (list 'def 

(concat 'is- type '- (car body) '?) 
(list 'macro 
'(body) 

(list 'list 
"eq 

(list 'list 
"car 

‘(cadr body)) 

(list ‘list 
"quote 
(list 'quote 

(car body)))))) 

(append 

(defstruct-lony-fields 
type (car body) (cadr body) 2) 
(defstruct-replace-fields 
(concat (car body) '- type) 

(cadr body) 

Figure 3.3 The defstruct-lony Definition Without Backquote 
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3. Lincoln.) Macros 



Among the wide variety of macros in lincoln.l, one of them, causes 
inline lambda expressions to be automatically quoted. Recall that quote is 
normally used to inhibit evaluation of LISP forms, function is used in a 
similar fashion to prevent functions from being evaluated. Since most inline 
lambda expressions require quoting, in lincoln.l lambda is defined as a 
macro that automatically includes function in front. (Wilensky, 1984, pp. 
119 & 185) Here is its definition:'? 

-> (eual-iuhen (compile load eual) 

(def lambda (macro (body)$(function ,body))) )<CR> 

Several other macros in lincoln.l create mnemonic names for 
frequently used operations. The defstruct macro generates data structures 
and makes other macros to manipulate the structures. However, the 
majority of lincoln.l macros are predicates. 

a. Numerical Comparison Predicate Macros 
The macros = 0 , < 0 , > 0 , <= 0 , >= 0 , <> 0 , >=, <=, <>, and =1 
represent predicates which check the conditions given in Table 3.2. Their 
syntax, with the exception of <= and =1, is also used for the MacPitts 
comparison primitives (Lincoln Lab Report 662, 1983, p. 49). Note that LISP 
has <= and >= primitives. LISP primitives for increment (1+), decrement 
(I-), add (+) , subtract (-), equality (=), etc., are also used for MacPitts 
functional syntax. Each of these macros corresponds to a layout primitive 



"? macro and niambda are also similarly defined. 
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called an organelle which is covered in Chapter VI. (Siskind, 1982, pp. 14- 
15)(Lincoln Lad Report 662, 1983, pp. 25-26) 



TABLE 3.2 

NUMERICAL COMPARISON PREDICATES 



Predicate Name 



Name Predicate Test 



=0 

<0 

>0 

>=0 

<=0 



equality with zero 
negative sign 



non-negative value 
non-positive value 
less than or equal 



positive sign 



<= 

>= 

<>0 

<> 

= 1 



greater than or equal 



not equal to zero 
not equal 



equality with one 



In addition to the numerical comparison macros shown above, 
lincoln.l has several macros that perform type checking, 
b. Type Predicate Macros 

LISP’S applicative nature allows functions to be passed as data and 
provides data handling flexibility at the expense of performing very little 
type checking.® (Gray, P., 1984, p. Ill) Whereas in LISP predicates usually 
have the form <name>p, in linconl.l they have the form <name>?. Take for 
example a LISP and a lincon.l predicate that checks if a number is odd; 

-> (oddp 3)<CR> 

;; LISP predicates often end in a ” p “. 

t 



® For a discussion of type checking see (Aho, 1986, pp. 343-380). 
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-> (odd? 2)<CR> 

;; lincoln.l predicates usually end in a " ? 

nil 



In Franz LISP the function type returns one of fourteen types. 
(Foderado, 1983, pp. 1-1 through 1-6)(Wilensky, 1984, pp. 246-260) Table 
3.3 gives a list of lincoln.l predicates and their meanings: 

TABLE 3.3 

TYPE PREDICATES AND THEIR MEANINGS 



Predicate Name Predicate Meaning 



array? 

atom? 

bignum? 

bound? 

eg? 

equal? 

even? 

flH? 

fiunum? 

flonum? 

function? 

list? 

null? 

number? 

odd? 

string? 

member? 



is it an array? 

is it non-nil and not a list? 

is it an integer greater than a fixnum? 

has it been given a value? 

are they the same structure? 

do they return the same value? 

(are they equivalent?) 
is it even? 

is it a fixnum or a bignum? 

is it an integer between -2^i and 2^^ - 1 ? 

is it a floating point number? 

is it a machine coded function? 

is it nil or a list? 

is it null? 

is it a bignum, fixnum or flonum? 
is it odd? 

is it a sequence of characters? 
is an element a member of a list? 



Macros are used in lincoln.l to create a consistent set of 



primitives out of many LISP functions that evolved with disparate formats. 
In addition to homogenizing existing LISP functions with macros, lincoln.l 



also provides a large number of functions. 
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B. FUNCTIONS 

1. API Like Operators 

APL was one of the first programming languages to apply functions 
over whole data structures, thereby freeing the programmer from the 
tedium of iterating over elements.^ John Backus, one of FORTRAN’S creators, 
wanted to reason algebraically about programs and suggested applying API’s 
ideas in a purely functional manner. The operations of this algebra would 
consist of applying, binding, selecting, "composing, reversing, mapping and 
reducing functions." (hacLennan, 1983, p. 405) 

Several functions are shown here as examples of the many useful 
functions with an APL flavor in this section: 

-> (such-that '(0-19 -2 -3) '<0)<CR> 

;; (such-that <list> <predicate>) 

;; Return all list elements satisfying the predicate. 

(-1 -2 -3) 

-> (slash '((a b c)(d c a b)(e f g b)) nil 'union)<CR> 

;; (slash <list> <identity> <function>) 

;; Return the result of applying a function to a list’s elements. 

(a b c d e f g h) 

-> (sort '(1 4 2 5 3 9) '>)<CR> 

;; (sort <11st> <pred1cate>) 

;; Sort a list’s elements by a predicate. 

(9 5 43 2 1) 

-> (car-list ((1 2)(3 4)(5 6)))<CR> 

;; (car-list <list>) 

;; Find the first element of each of a list’s sublists. 

(1 3 5) 



9 For an excellent APL user’s guide see (IBM, 1983, p. 13). 



83 



-> (replicate 4 '(man))<CR> 

;; (replicate <integer> <LISP form>) 

;; Copy a LISP form an Integer number of times. 

((inan)(man)(man)(man)) 



2. Selection Functions 

Franz LISP and APL both have a repertoire of list selectors.^o Some of 

lincoln.rs are shown;i ^ 

-> (nthset 3 (fl B C 0) e )<CR> 

;; (nthset <index> <list> <L1SP form>) 

;; Replace the indexed position with a given LISP form. 

(fl B e D) 

-> (atliiasert 3 '(a b c d) 'U)<CR> 

- ;; (nthinsert <index> <list> <element>) 

;; Insert the element after the indexed position 

(abend) 

-> (nthdrop 3 *(fl 3 C B))<CR> 

;; (nthdrop <indexxlist>) 

(B B B) 

-> (nthelem-list 
(1 2 6 ) 

'(Many are called. Few are chosen.))<CR> 

;; (nthelem-list <index> <list>) 

;; Pick the indexed elements out of a list. Notice that LISP consi- 
;; ders a space as the delimiter between atoms (e.g. chosen, or 
;; called, are one atoml 

(Many are chosen.) 



>0 See (Foderado, 1983, p. 2-4) and (IBM, 1983, p. 52). 

1 ^ Compare to the selectors presented in Section II.C.3.b. 
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-> (nthset-list 
(1 4 6) 

'(Sad is the moman u»ho cries along the way.) 
mas simgs\ )<CR> 

;; (nthset-list < 1 ndex-list> <template-list> <new-element-list>) 
;; Replace the indexed positions in the template-list with the 
;; respective elements from the new-element-list. 

{Mappg is the maa who stags along the way.) 



3 . Set Functions 

A LISP list can be viewed as a set with elements, e.g.: 

{ element!, element 2 , ..., elementN } ;== (<element>*) 

<set> ;;= <list> 

With this point of view in mind lincoln.l provides a variety of set 
operators: 



-> (setifg ‘((a b)(a b c^(a P/M 2 'a /«/))<CR> 

;; (setify <list>) 

;; Remove redundant elements from a list. Notice that (a b) and 
;; (a) occur more than once in the list. Italics are for emphasis. 

((a b c)(a b) 2 'a (a)) 

-> (union '(1 2 3 4) ‘(2 3 5 4 6 7))<CR> 

;; (union <set>i<set>2) 

(1 2 3 4 5 6 7) 

-> (intersection ‘(1 2 3 4 5) ‘(3 4 5 6))<CR> 

;; (intersection <set>i<set>2) 

(3 4 5) 

-> (set- '(1 2 3 4 5) '(2 4))<CR> 

;; (set- <set>i <set>2) 

;; Remove set2 elements from set^. 

(1 3 5) 
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4. Numeric Functions 



The functions in this section deal mostly with integers or binary 
numbers; 



-> (to-binary 15 7)<CR> 

;; (to-binary <1nteger> <bits>) 

;; Create a list that represents the binary equivalent of an 
;; integer with the given number of bits. 

(0 0 0 1 1 1 1 ) 

-> (to**decimal ‘(0 0 0 1 0 1 1 0 1))<CR> 

;; (to-decimal <binary-number>) 

45 

-> (ceiling 4.5)<CR> 

;; (ceiling <number>) 

;; Return the least upper bound integer of a number. 

5 

-> (floor 4.5)<CR> 

;; (floor <number>) 

;; Give the greatest lower bound integer of a number. 

4 

-> (rand 100)<CR> 

;; (rand <number>) 

;; Return a random integer between zero and the given number. 
;; The result generated is a random integer and usually differs 
;; with different calls to rand using the same argument. 

94 

-> (deal 4)<CR> 

;; (deal <integer>) 

;; Make a randon list of the first four integers. 

(4 2 3 1) 

-> (deal-list '(1 2 3 4 5 6))<CR> 

;; (deal-list <list>) 

;; Randomly order a list. 

(2 4 1 3 5 6) 



86 



The wide spectrum of functions seen in this section crop up 
throughout MacPitts and LBS. Surprisingly enough though, a large portion of 
the functions encountered in these programs are generated by one macro: 

defstruct. 



C. DEFSTRUCTS12 

The lincoln.l defstruct [define structure macro! allows the user to 
create new data types. It automatically generates macros to create, select, 
change or type check instances of the data type. The following quote states 
the idea of a structure (Winston, 1984, p. 100): 

Conceptually, a structure is a collection of fields and field values. 
We are allowed to define new structures by specifying their particular 
field names and default field values. We are further allowed to construct 
individual structures of any already defined type, to access those 
individual structures, and to revise them. However, in keeping with the 
spirit of data abstraction, we are not allowed to look at the way individual 
structuresare represented internally, for we are supposed to be isolated 
from the actual representation. 

Defstructs are frequently used throughout LBS and MacPitts. They are a 
useful tool when a large number of different data types must be 
manipulated. The defstruct macro creates short or long data structures. 

1. Short Defstructs 

The short defstruct has the following format: 

<short form> ::= (<field>‘*' I { <field>*<1ist> }) 

<field> ::= <symbol> 



^2 Refer to the examples in Section III.A.2. Lincoln.l's defstruct macro 
is slightly different from those found in other versions of LISP. 
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Therefore, a short defslruct looks like a list with fields which are all 

symbols, except for the last field which can be a list. But, there is more to 

this structure idea than just the list format: evaluating defstruct creates 

a data type with the specified fields. In addition, defstruct automatically 

generates three other macros: one to construct instances of the data type 

(constructor), another to select field values (selector), and finally one to 

change field values (mutator). Streching BNF a bit [a short defstruct has 

three functions and a list of fieldsl, this is represented as: 

<short-defstruct> ::= -> (defstruct <type> <short form>)<CR> 
<short-defstruct> ::= <short-selectorxshort-mutator> 

<short-constructor> 

(<field value>‘^ I { <field value>*<list> }) 



a. Short Constructor 

To create instances of a data type with parameters for the fields 

a constructor macro of the following format is used: 

<short-constructor> ::= make-<type> 

(<field value>"^) ::= -> (make-<type> Cl<fie1d-value>'^)<CR> 

For example:'^ 

-> (defstruct poiat 

(name h y layer attributes) )<CR> 

;; Create a data list of the form: (name x y layer attributes). 

;; Defstruct returns the name of one of the macros it creates. 

replace-point-attributes 

-> (make-point ’in 3 7 ‘NM *((siynal)(riuer)))<CR> 

;; Instantiate a point data type with the given parameters, e.g. 

;; name := in, x := 3, y := 7, layer := NM, etc.. 

(in 3 7 NM ((siynaD(riuer))) 



A point is fully described in Chapter IV.A.2. 
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Notice that the result is a list with all the field values placed in 
the order they were entered, 
b. Short Selector 

Defstruct also creates selector macros to obtain field values. A 
short selector macro that picks out <field>^ of a <type> short defstruct has 

the format: 

<short-selector> ;:= <type>-<field>^ 

<field-value>i ;:= 

■ -> (<type>-<field>^ {‘(<field-value>+) I 

(list I'l<field-value>+)} )<CR> 



For example: 

-> (point-name '(in 3 7 NM ((signal)(riuer))))<CR> 

;; Get the point’s name: 

in 

-> (point-attributes '(uss -2 7 ND ((pouier)(out))))<CR> 

;; Get the point’s attributes: 

((pomerHout)) 

c. Short Mutator 

The third macro automatically generated for a short defstruct is 
used to change field values. Mutators replace a <type> defstruct’s <field- 
value>,- with <field->7^?j'K-value>^ and have the following form: 

<short-mutator> ::= replace-<type>-<field>i 
(<field-value>^...<field-y7^?j+‘-value>i ...<field-value>fj) ::= 

-> (replace-<type>-<field>i 

{ *(<fie1d-value>‘^) I (list (']<field-value>‘'‘) } 

{ I']<field-/7*f?j+‘-value>i })<CR> 
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The following examples illustrate the use of mutators; 

-> (replace-point-layer 

'(in 3 7 NM ((signaD(input))) 

•NP)<CR> 

;; Replace the point's layer with NP; 

(in 3 7 NP ((signaD(input))) 

-> (replace-point-y 

'(in 3 7 NM ((signaD(riuer-router))) 

11)<CR> 

;; Replace the point's y coordinate with 1 1: 

(in 3 1 1 NM ((signaO(rluer-router))) 

Short defstructs are an application of the principle of data 
abstraction to a list. Each field is given a name, and functions which use 
those names to manipulate the structure are automatically created. This 
idea is carried one step further in the long defstruct to allow 
differentiating between closely related structures. 

2. Long defstructs 

An extension of the short structure concept which allows the fields to 

be data structures and includes type checking is the long structure. The type 

is the genus^^ and the cases the species . The long structure's syntax is 

superficially the same as a short structure format; 

<long form> ;;= { <case> ({<case-field>+ 1 <case-field>*<list>}) }■*■ 
<case-field> ;;= <symbol> 

<long-defstruct> ;;= -> (defstruct <typexlong form>)<CR> 
<long-defstruct> ;;= <long-constructorxlong-selector> 

<long-mutatorxlong-interrogator> 

{(<case> {<case value>+ I <case value>*<list>})}+ 



'“In Aristotelian logic, a very wide and comprehensive class or kind, 
subclasses of which may be called species." (Flew, 1979, p. 131) 
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In both the short and long structure cases defstruct is used. A long 
defstruct example with a tree genus and eight species: 

-> (defstruct tree 
null 0 

rect (lager left bottom right top) 

sgmbol-call (name) 

moue (tree dH dg) 

rotcui (tree) 

rotccui (tree) 

mirrora (tree) 

mirrorg (tree))<CR> 

This long structure creates a tree data type. There are eight tree 
cases; null, rect, sgmbol-call, moue, rotcui, rotccui, mirrora and 

mirrorg^^. Note that five of the tree cases have a tree in their field. The 
field'arguments are also defstructs! A long structure has four associated 
functions: constructors, selectors, mutators and interrogators, 
a. Long Constructor 

As in the short structure, macros to construct data type instances 
are automatically generated in the long structure. A constructor that 
Instantiates the species <casei>-<type> has this format; 

<long-constructor> ;:= malce-<case><-<type> 

(<case>i «case>i-field-value>*) ;;= 

-> (molce-<case>i-<type> { (*l«case>,-field-value>}+)<CR> 



^SThese eight cases correspond to eight basic operations on rectangles. 
Null is no action or no rectangle. Rect is a rectangle with the given layer 
and dimensions. Sgmbol-call represents a method for generating 
hierarchical representation. Moue, rotcui, rotccui, mirroru and 
mirrorg represent respectively a displacement by dx and dy; ninety degree 
clockwise and counterclockwise rotation; and a flip about the x axis or the y 
axis. The operators these trees represent are described in (Crouch, 1984, p. 
8 ). 
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This is best shown in a few examples; 



“> (make-rect-tree 'NO 0 12 3)<CR> 

(rect NO 0 1 2 3) 

-> (mak8-null-tr8e)<CR> 

(null) 

-> (fnake-fnoue-tr88 *(r8ct NO 0 1 2 3) 5 9)<CR> 

(mou8 (r8ct NO 0 1 2 3) 5 9) 

b. Long Selector 

In order to pick <field>i‘s value out of a <case>i-<type> species the 

following format is used: 

<long-selector> :;= <case>i-<type>-<field>j 

<case>i-<field>j-value ::= 

-> (<case>i-<type>-<field>j 

{'(<case>j «case>rfield-value>+) I 
(list { [']<case>i }{ [*]«case>i-field-value> }* ) } )<CR> 

A few examples can make this clearer: 

-> (rect-tr88-lager *(r8ct Nl 1 2 3 4))<CR> 

Nl 

-> (mou8-*tr88-tr88 ‘(mou8 (r8Ct Nl 1 2 3 4) 5 9))<CR> 
(F8Ct Nl 1 2 3 4) 

c. Long Mutator 

Field values are modified in a fashion similar to the short 
structure mutator, in order to replace <f1eld>j of species <case,->-<type> a 

long mutator must be used as follows: 
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<long-mutator> ::= replac8-<case>i-<type>-<field>j 
(<case>j 

«case>i-<field>, -value) ... 

«case>j-<field>j-/7^?j-i'^value> ... 

«case>,-<field>N-value> ) ::= 

-> (replace-<case>p<type>-<field>j 
{'(<case>^ «case>i-field-value>+) I 
(list { [']<case>i }{ [’]«case>pfield-value> K ) } 
{[']«case>i-<field>j-/7^?J-K-value>} )<CR> 

This is best seen in a few examples: 

-> (replace-rect-tree-top '(rect NM 1 2 3 4) 15)<CR> 

;; replace a “rect-tree“ species' “top" field with 15. 

(rect NM 1 2 3 15) 

-> (replace-moue-tree-dy 

‘(move (rect 1 2 3 4) 9 8) 

11)<CR> 

;; replace a “move-tree" species' “dy" field with 1 1. 

(moue (rect 1 2 3 4) 9 11) 

The tree example has shown that a long structure adds a level of 
complexity to the defstruct concept. Why bother? Because there is a big 
advantage to be gained in grouping similar ideas together and then 
differentiating between them. In order to do this a long defstruct also 
creates interrogators. 

d. Long Interrogator 

Long structures offer a limited form of data type checking with 
their interrogator macros. A check to see if a structure is a <case>^-<type> 

species can be made as follows: 
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<long-inlerrogator> ::= is-<type>-<case>i? 

{t 1 nil} ::= 

-> (i$-<type>-<case>i? 

{’(<case>x «case>x-field-value>-^) I 
(list { l‘]<case>x }{ (‘]«case>x-field-value> }+ ) })<CR> 

For example: 

-> (is-tree-rect? '(rect NO 1 2 3 4))<CR> 

;; is " (rect ND 1 2 3 4) " a "rect-tree“ ? 

t 

-> (is-tree-nuil? ‘(rect ND 1 2 3 4))<CR> 

;; IS " (rect ND 1 2 3 4) a "null-tree" ? 

nil 

-> (is-tree-mowe? (moue (rect NO 1 2 3 4 ) 5 9))<CR> 
j; Is “ (move (rect ND 1 2 3 4) 5 9) " a "move-tree" ? 

t 

Keep In mind that the interrogator macro only checks that the 
correct case name is at the head of the list which composes the data 
structure. In other words, no check is being made to ensure the correct value 
types are being placed in the field slots, or even that the structure has the 
correct number of fields! 

3. General Field Structure Checks 

defstruct checks its first two arguments to determine whether a 
short or long format is required. If its first argument is an atom and the 
second argument a list then a short format is made. If its first argument is 
an atom and the second argument is also an atom then a long format is made. 
Otherwise, an error message is printed if the fields are null or the first 
argument is a list. 
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The other check thot is made ensures that only the last field in a 
defslrucl is a list. This occurs in litifstrucc-siiuri-fieids aiiu 
Uefslnjct-iuny-fitiJds where the fields are also checked to be not etnuty. 



4. Summar u 

defstruct offers the programmer a tool for data abstraction. This 
idea along ’with the mnemonic character of constructors, selectors, 
mutators and interrogators are great aids in data manipulation, defstrucls 



are extensively used in LBS and nacPitts. It might also be speculated that to 
some degree the mind-body paradigm is reflected in MacPitts' function-data 
language and controller— data-path architecture. In any case. Table 3.4 



presents a defstruct summary; 

TABLE 3.4 



DEFSTRUCT FUNCTION SUflflARY 



Function 

Constructor 

Selector 

Mutator 

Interrogator 



Short Structure Lon g Structure 

niQk8-<typs> maSca-<ca36>i-<type> 

<type>-<field>, (case>i-<type>-<field>, 

replace-<type>-<field>i repSac8-<cas8>j-<typ8^- 
None fs-<type>-<case:,? 
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IV. LINCOLN LABORATORY LISP LAYOUT LANGUAGE; L5 



L5 is a LISP based language for hierarchical representation and 
manipulation of VLSI circuits. It uses the basic predicates, functions and 
data structures provided in lincoln.l to create operators for manipulating 
rectangles and points. With these two building blocks more complex 
structures can be built. These constructed units can then be used as basic 
blocks to create other structures in a hierarchical fashion. 

A. GLOBAL VARIABLES AND DATATYPES 

Global variables in L5 are used to determine aspects of the technology the 
circuit will be implemented in; and, thereby constrain the permissible ways 
data is manipulated. There are several data types in L5. They are created and 
handled in a consistent manner using flefst^uct^ 

1. Global Variables 

There are several global variables in L5 that toggle other processes 
and thereby affect the behaviour of LBS or nacPitts. The most important 
ones deal with setting technology dependent factors such as mask layers, 
process dimensions (Microns/lambda; p/Xl, etc.. The user is provided with 
functions to access these global variables and check or modify their status. 
Table 4.1 lists global variables and their functions as a convenient 
reference: 



^ Refer to Chapter III 



TABLE 4.1 

GLOBAL VARIABLES AND THEIR FUNCTIONS 



Variable 


Status Check 


Status Modifier Ootions 


— L5-symbol- 


(L5-symbol- 


(L5-symbol-storage! 


storage 


storage) 


[']{<on-disk I 
in-memorg>}) 


— L5-technology 


(technology) 


(technology! [‘]{<nmos 
1 cmos 1 cmos-pui I 
cmos3 1 sosi scmos>}) 


— L5-minimum- 


(minimum- 


(minimum-feature- 


feature-size 


feature-size) 


size! <centi-)u per \>) 


— L5-sgmbol-list 


(L5-sgmbol-list) & 
(create-called- 
symbol-item 

<posit1on>) 


(add-sgmbol-to-L5- 
symbol-list <symbo1>) 


— L5-sgmbol- 


— L5-symbol- 


(setq — L5-sgmbol- 


number 


number 


number <integer>) & 

(symbol-number) 


— L5-sgmbol-port 


(L5-sgmbol-port) 


(setq — L5-sgmbol- 

port <port>) 


“L5-sgmboI-file 


(L5-sgmbol-fiie) 


(setq “L5-sgmbol- 
file <file>) 




(allomed-lagers) 






(allouied-conducting- 

lagers) 




(lager-table) 




%% 


(allouied-technologies) »» 



All of the global variables can be changed using setq. Functions with, 
operate by checking the technology global variable and returning an 
appropriate response without setting any variables. The, , denotes that to 
change the values returned by these functions the LISP source code has to be 
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iTiodi f'ied. Finai’iy, Ui6 operator' 'wirn, is d constant 



function that doesn't 



set any variables and r'eturns, 

(iimos emus emos-ptu cmos3 sus semos) 



Global variables may have different default values; 

TA6LE 4.2 



GLOBAL VARIABLE DEFAULT VALUES 



Global Variable 


Default V' 


— L5-symbol-storage 


on-disk 


— L5-symbol-port 


nil 


--L5-sgmbol-filc 


nil 


"L5-symbol-!isl 


ni! 


— L5-sgmbol-number 


nil 


"L5-technologg 


nmos 


— L5-minimum-feature-size 


250 


— L5-read-stac3c 


nil 



When the function L5-symboi-fiie [or L5-symboi-porti checks 

its associated global variable’s value and finds it to be nil. then the symbol 
file [or symbol port! is changed so that it’s located in the /Imp directory. 
The file name is formed by concatenating the current UNIX® process number 
with an acronym for L5 symbol, " LBsyrn ". Therefore, global variables 
operate in the following fashion:^ 

% ps<CR> 

^ Give the current UNIX® process number. 

12904 



% lisp<CR> 

[Franz Lisp Opus 38.59] 



2 A discussion of the symbol list is postponed until the symbol 
defstruct in this section and the defsymbol function in Section IV C. !. 
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-> (l5-symbol-f!le)<CR> 

This file is used to output CIF^ results. 

/tmp/L5sym 1 2904 

-> (L5-symbol-port)<CR> 

;; A port is a LISP I/O device. 

%/tmp/L5sym 1 2904 

-> (technology! 'cmos)<CR> 

;; Set the technology to cmos and list out its layers. 
;;These symbols correspond to GIF layers, e.g. CD = n-type 
-diffusion, CP = polysilicon, CM = first layer metal, etc.. 

(CO CP CM CM2 CS CC CG CIO NH HP) 

-> (technoiogy)<CR> 

;; The current technology is complementary metal oxide 
;; semiconductor 

cmos 

-> (technology! 'scmos)<CR> 

;;These are Calma scalable cmos CIF layers, e.g. CMS = 
;jmetal2, CMF = metal 1, CPG = polysilicon, etc.. 

(CMS CMF CPG COB CUB CCP CCB ClilP CUIN 

CSP CSH C06) 



-> (minimum-feature-size! SO)<CR> 

;; Set 50 centimicrons to be 1 lambda unit. 

50 

-> (minimum-feature-size)<CR> 

;; Currently 50 centimicrons are 1 lambda unit 

50 



’ ’The Caltech Intermediate Form (CIF Version 2.0) is a means of 
describing graphic items (mask features) of interest to LSI circuit and 
system designers." (Mead, 1980, p. 115) Also see (Sequin, 1980, Chapter 7) 
and (Scott, 1986, Magic Tutorial ^9 and Magic Technology Manual ^1-2). 
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-> (allouiecl-technoiogies)<CR> 

;; These are the technologies for which CIF layers have 
;; been entered Into L5. 

(nmos CHIOS cmos-pui cmos3 sos scmos) 

-> (allouied-layers)<CR> 

;; Return the current technology's layers; 

(CMS CMF CAR CUR CCP CCR CUIP CUIN 

CSP CSN C08) 

-> (pp allouied-conducting-lagers)<CR> 

;; Pretty print the definition of the function " allowed- 
;; conducting-layers Examining the result reveals that 
;; this function is simply a large conditional statement 
;; that checks the current technology and returns a list of 
;; conducting layers. To add another set of conduction 
;; layers, simply add the new technology name to the list 
;; In the body of allowed-technologles and add a 
;; statement In allowed-conducting-layers of the form: 

;; ((eq *<new-tech>) (technology)) '(<layer-list>)) 

(def allowed-conducting-layers 
(lambda 0 
(cond 

((eq ‘nmos (technology))'(NM NP ND)) 

((eq cmos (tectinologg))‘(CM CP CO CM2)) 
((eq 'cmos3 (technology))‘(CM CP CD CM2)) 
((eq 'SOS (technology))*(SM SP SIS)) 

((eq 'cmos-pw (technology))'(CM CP CO)) 
((eq 'scmos (technology))'(CMS CMF CPG CSP 
CSN)) 

(t (L5-err '1 That technology is not 
recognized by LSI)))) 

Global variables and their effects will again be encountered in 
Section IV.C, In the meantime, a look Is taken at L5's data types. 
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2. L5 Data Structures 



All L5 data structures are created using defstnict. The generic 
object in L5 is called an item and is composed of rectangles and labels. 
(Crouch, 1983, p. 2) Since an item is a grouping of smaller objects it is 
surrounded with an imaginary rectangle (box] which encompasses all its 
elements. The smallest box which encloses an item is called the Minimum 
Bounding Box (MBB). (Ayres, 1983, p. 64) The syntax for an item is: 

TABLE 4.3 





AN ITEM’S SYNTAX 


Category 
,<item> :;= 

{<left>|<bottom>| 


Syntax 

(<left><bottom><right><topxpoints> 

<called-symbol-namesxtree>) 


<right>|<top>} ::= 
<points> ::= 
<point> ::= 
<attributes> ::= 
<called-symbol- 


<number> 

(<point>*) 

(<namexxxyxattributes>) 

{ (<symbol>*) 1 ({(<symbol>)}*) } 


names> ::= 
<tree> ::= 

<null-tree> ;:= 
<rect-tree> ::= 
<symbol-call- 


(<number>*) 

{ <null-tree> I <rect-tree> I <symbol-call-tree> j 
<move-tree> 1 <rotcw-tree> 1 <rotccw-tree> I 
<mirrorx-tree> I <mirrory-tree> } 

(noli) 

(rect <layer><leftxbottomxnghtxtop>) 


tree> ::= 
<move-tree> ::= 
<rotcw-tree> :;= 
<rotccw-tree> :;= 


(symbol-call <number>*) 
(move <tree>) 

(rotcv <tree>) 

(rotcciv <tree>) 



<mirrorx-tree> ;:= (mirrom <tree>) 

<mirrory-tree> :;= (mirrorg <tree>) 

An item structure contains two other structures within it; a list 

of point short structures and a tree long structure. First, a look at the 

item structure and the creation of a simple item: 
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-> (defstruct item 

(left bottom right top 
points 

called-symbol-names 

tree)) 

;;The left, bottom, right end top .fields describe the (IBB, 
;; > e., Xrnax, ymax- The points field contains a 

;; list of points [labels]. The next field is a list of digits 
;; indicating which symbols on the L5-symbol-list are 
;; used by this item. The tree field is a list summarizing 
;; operations performed on the item, 
repiace-item-tree 

Since an Item is a short defstruct it comes with constructor, 
selector and mutator macros. For example, to create an item composed of a 
metal and a diffusion rectangle with two point labels: 

-> (make-item 12 3 4 

‘(((in) 1 2 NM (pomer)) 

((out) 2 2 NO (euternal))) 
nil 

((rect NM 1 2 2 3) 

(moue (rect NO 0 0 1 1) 2 3))) ) 

;; Make an item with a MBB with coordinates (1 2) and 
;; (3 4), an "in" label at (1 2) on metal, an "out" label 
;; at (2 2) on diffusion, and no symbol calls. The 
;; primitives this item is composed of are: 

;; (1) A metal rectangle with coodinates (I 2) and (2 3) 

;; (2) A diffusion rectangle with coordinates (0 0) and 
;; (1 1) that has been translated to the right 2 units 

;; and to the top 3 units. 

(12 3 4 

‘(((in) I 2 NM (power)) 

((out) 2 2 NO (euternal))) 
nil 

((rect NM 1 2 2 3) 

(moue (rect NO 0 0 1 1) 2 3)))) 
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As is seen in the above example, a list of points is a field in an item. 
The point short structure is implemented as follows: 

-> (defstruct point (name k y layer attributes)) 

;; A point is a label. Points have names, are located at 
;; a specific x and y location and are attached to a layer. 

;; A point's attributes can give descriptive information 
;; to guide functional application. For example: points 
;; with the attribute “externar are actually plotted when 
;; CIF is created; the power attribute is used by the 
;; function power-line-positions (in the MacPitts program 
;; organelles.l] to find Vdd or Vss locations . These 
;; positions are then used by layout-metal-lines [in 
;; organelles.l] to lay down a metal line grid, 
replace-point-attribntes 

An example now shows the creation of a point: 

-> (make-point '(in) 1 2 ‘CM 

‘((poiuer)(eHternal))) 

;; Make a point whose name is "in“, located on CMOS metal 
;; at (1 2), and with "power" and "externar attributes. 

((in) 1 2 CM ((pouier)(eHternal))) 

An item's fifth field is a summary of other items used to construct 
the item. This <ca11ed-symbol-names> field is composed of a list of 
numbers. These numbers represent symbols. A symbol is a structure 
containing an item's salient information. Computer time and memory use are 
reduced when frequently used items are constructed once and then referred 
to whenvever needed. Whenever an item is made using the defsymbol 
function (See Section IV.C.1], a pseudo-item, a symbol, is placed in the L5- 
symbol-list. Any use of this item will be reflected in the <ca11ed-symbol- 
names> field; these numbers indicate a symbol's position in the 15- 
symbol-list. A symbol has the following structure: 
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-> (defstruct symbol 

(ID left bottom right top points 
internal-symbols nest-leuel tree)) 

;; Symbols are used by the defsymbol** function. Defsym- 
;; bols are items that are immediately stored in GIF 
;; format in the L5-symbol-file.5-A symbol representing 
;; the item is then placed on the L5-symbol-list. The L5- 
;; symbol-list has a symbol for each defsymbol that 
;; has been called; consequently, future calls to a 
;; defsymbol with the same parameters are referred to in 
;; the calling item’s called-symbol-names position la list 
;; of numbers giving the position in the L5-symbol-list of 
the symbol representing the called defsymbol). 
replace-symbol-tree 

An item's final field is a tree, with the following structure: 

-> (defstruct tree 
null () 

rect (layer left bottom right top) 

symbol-call (name) 

move (tree) 

rotcui (tree) 

rotccui (tree) 

mirroru (tree) 

mirrory (tree)) 

;; A tree is a representation for an item operator^. An 
;; item's tree is a summary of all the operations 
;; performed on the item. A macro name is returned. 

replace-mirrory-tree-tree 

L5's major data structures are items, points, symbols and trees. 
They provide a framework for manipulating geometric objects. 



See Section IV.C.1 for more on defsymbol. 

5 This occurs only when the L5-symbol-storage is set to ‘’on-disk”. 

6 See Section IV. B. 2 for a discussion of item operators. 
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B. ITEMS AND THEIR OPERATIONS 

The item data structure is the basic building block in L5. However, 
having to use the make-item function can be a bit tedious. Therefore, L5 
has primitive functions for creating rectangles [or boxes] and marks [a 
point that has an item format], L5 also has operators for moving, rotating, 
etc., items and their points. Items and marks can be grouped together to 
form larger units using the merge function. 

1. Item Creation 

L5 has four functions for creating primitive items; null-item, rect, 
boH and mark: 

TABLE 4.4 

FOUR PRIMITIVE ITEM CREATING FUNCTIONS 



Function 



Arguments 



null-item 

rect 

bOH 

mark 



none 

<layer><x^i,><y^<„><Xrnax><ymax> 

<layer><length><widthxxcenter><y«ntw> 

<name><x><y><layerxattributes> 



Some examples of these primitive functions are; 



-> (null-item|<CR> 

;; A null item is useful as a default value for a conditional since 
;; it has an item's format with only null fields [Crouch, 1983, p.5] 

(nil nil nil nil nil nil (nulO) 



-> (rect XD 0 1 4 8)<CR> 

;; A rectangle has no points or symbol calls. It consists of its 
;; MBB coordinates (0 1) and (4 8) and a rect-tree. 

(0148 nil nil (rect CO 0 I 4 8D 



Note the difference between the <LISP form>, (rect XD 0 1 4 8), and 
the <expression>, (rect CD 0 1 4 8). The first is a function, the second is a 
data object. The first evaluates its arguments, the second is a list of 
parameters. Refer to Section II.C.1. 
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-> (boH CM 2 8 6 4)<CR> 

;; A box is an alternate method of defining rectangles. It's 
;; similar to the way CIF defines boxes. 

(5.0 0.0 7.0 8.0 nil nil (rect CM 5.0 0.0 7.0 8.0)) 

-> (mark 'in 5 6 'CMF '(eHternal))<CR> 

;; A mark is a point that has an item shell built around it. Notice 
;; that the name is automatically converted to a list whereas in 
using make-point it had to be input as a list^. The name can be 
;; an atom or a list of atoms. Attributes can be either a list of 
;; atoms or a list of lists; (<atom>*) or (<list>*). 

(5 6 5 6 (((in) 5 6 CMF (eKternal))) nil (null)) 

With rectangles and labels any Manhattan geometry can be 
represented by joining or moving these basic elements. 

2. Item Operators 

L5's flexibility is due to the many functions that it contains for 
performing common layout operations so that complex structures can be 
built up hierarchically from simple building blocks. (Crouch, 1983, pp. 8- 
1 1 1^ Many of these operations either move or join objects, 
a. Translation and Merging Operators 
All layouts in L5 are referenced to an imaginary grid in lambda 
units with center at (0 0). The next group of functions work within this 
Cartesian framework to assemble or shift items: 



8 L5 functions which search among points in an item assume that a 
point's name is a list. See the functions find or align in Section IV. 8.2. 

9 For a discussion of desirable operators see (Ayres, 1 983, pp. 84-88]. 
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TABLE 4.5 

TRANSLATION AND MERGING OPERATORS 



Function 


Arguments 


Descriotion 


move 


<item><dxxdy> 


move an item.by dx and dy units 


home 


<item> 


place item's top left at (0 0) 


first- 


<item> 


place item's bottom left at (0 0) 


qvodrant 


second- 


<item> 


place item's right bottom at (0 0) 


quadrant 


third- 


<item> 


place item's right top at (0 0) 


quadrant 


fourth- 


<item> 


same as home 


quadrant 


merge 


<item>+ 


make one item out of several items 


merge-llst 


(<item>+) 


make one item out of a list of items 


align 


<item> 

<point-name> 

<coordinate> 


move an item so that the named point 
is placed on the given coordinate 


align-items 


<item>i 

<point-name>i 

<item >2 

<point-name >2 


<item >2 is moved so that its named 
point aligns with <1tem>i's point 


rotcup 


<item> 


rotate 90* clockwise about (0 0) 


rotccw 


<item> 


rotate 90* counter-clockwise . . . 


mirrorn 


<item> 


mirror about the x axis 


mirrorg 


<item> 


mirror about the y axis 



A brief look at the application of some these functions follows: 

-> (move 

'(0 0 10 10 nil nil (rect NM 0 0 10 10)1 3 5)<CR> 
;; Move the metal rectangle to the right 3 units and up 5 units. 

;; Notice how only the MBB is changed [addition and consing 
;; elements Into a list are fasti. I.e. The result of the operation 
;; could have been: (3 5 13 15 nil nil (rect NM 3 5 13 15)), but 
;; if the tree was composed of many elements then each one 
;; would need to be moved also! 

(3 5 13 15 nil nil (move (rect NM 0 0 10 10) 3 5) 
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-> (let 

;; Set test-item ;= (-3 0 6 12 (((vss) ...) nil ((rect...)(rect...))) 

((test-item 
(-3 0 6 12 

(((uss) 1 2 NM (eHternal))((in| 3 4 NO nil)| 
nil 

((rect NM -3 0 0 4)(rect NO 0 0 6 12)1 ) ) ) 

;; Move test-item so the vss point is at (0 0). 

(align test-item ‘uss ‘(0 0)) )<CR> 

;; The result; 

(-4 -2 5 10 

(((uss) 0 0 NM (eHternal))((in) 2 2 NO nil)) 
nil 

(moue 

((rect NM -3 0 0 4)(rect NO 0 0 6 12)) 

-1 - 2 )) 

Before proceeding with other examples a primitive layout item 
available in MacPitts, a layont-inuerter iFigure 4.1) Is introduced: 

-> (layout-inuerter 4 t)'o<CR> 

;; This is an inverter defsymbol composed of several cuts which 
;; are also defined as defsymbols. Note that the item’s tree is 
;; a symbol call, indicating that this item has a symbol in the L5- 
;; symbol-list. The item is composed of <symbol>s ,^4 ^ 7 and is 
;; itself <symbol >7 
(0 -20 20 0 

(((gnd) 10-18 NM (power)) 

((ini) 14-20NP (in)) 

((udd) 8 -2 NM (power))) 

(1 4 6 7) 

(symbol-call 7)) 



>0 The lagoot-inuerter function is found in organelles.l [part of 
MacPitts]. Its syntax is; (lagont-inuerter <pu11up/pu11-down 
ratio><mark>) 

<mark> { 1 1 nil } 

Toggling <mark> to t places a label at the "in” point; 

(mark 'ini 14 -20 ‘NP '(in))) 
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clfplot* Windows -50J00 0 -5000 0 Scales 1 micron Is 0.115 Inches < 2921x) 

layout- Inver ter-4-t-2. SuperL 




Figure 4.1 (lanout-inverter 4 t) 
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This item con be menipulatecl as follows; 



-> (mirroFM (iiigout-*lnperter 4 t))<CR> 

;; Flip the inverter about the x axis. 

(0 0 20 20 

(((gnd) 10 10 NM (poiver)) 

((ini) 14 20 NP (in)) 

((udd) 0 2 NM (power))) 

(1 4 6 7) 

(mirrern (sgmbol-call 7)) ) 

More complex objects can be created out of previously defined 
items as seen in the next examples (See Figures 4.2 and 4.31: 

-> (let 

((inuerter (layout-inuerter 4 t))) 

(align-items 

inuerter 'udd (roirrorn inuerter) 'udd))<CR> 

;; Align the inverter and its mirror image so they have a common 
;; Vdd power point. 

(0 -20 20 16 

(((gnd) 1 0 -1 0 NM (power)) 

((ini) 14-20 NP (in)) 

((udd) 0 -2 NM (power)) 

((gnd) 10 14 NM (power)) 

;; The next point was cutoff by the plotting routine. 

((ini) 14 16 NP (in)) 

((udd) 0 -2 NM (power)) ) 

(1 4 6 7) 

((sgmbol-call 7) 

(moue (mirrorn (sgmbol-call 7)) 0 -4i))) 

The next item, shown in Figure 4.3, illustrates the use of the 
merge operator. Notice that this item has the output of one inverter 
connected to the Vss power source; and as such, is a non-operational layout. 



no 




Figure 4.2 (align-items inverter 'udd (mirrorn inverter) 

‘vdd) 



1 1 1 






-> (let 

((inoerter (lagoat-inverter 4 t))) 

(merge inverter (move inverter 20 0)) )<CR> 

;; Merge the inverter and its moved image (Figure 4.3], 

(0 -20 40 0 

(((gnO) 18-18 NM (pomer)) 

((ini) 14-20NP (in)) 

((vdd) 8 -2 NM (pomer)) 

((gnd) 38 -18 NM (pomer)) 

((ini) 34-20NP (in)) 

((vdd) 28 -2 NM (pomer)) ) 

(14 0 7) 

((sgmbol-call 7) 

(move (mirrom (sgmbol-call 7)) 0 -4))) 

The next operators aid moving and merging operations, 
b. Query Operators 

L5 has a group of operations that return an item's width and 
length, check if an item is null and abbreviate the defstruct field 
selector functions for the MBB dimensions (e.g., item-left is shortened to 
left]. The argument to all these functions is an item; 

TABLE 4.7 



ITEM QUERY OPERATORS 



Function 



Description 



is-item-null? 

left 

right 

top 

bottom 

item-midth 

item-length 



are the item's tree and points null? 

same as item-left 

same as item-right 

same as item-top 

same as item-bottom 

difference between the item's right & left’^ 
difference between the item's top & bottom 



A null-item's length or width is 0. Originally L5 returned nil for a 
null- item. A mark also has 0 length and width. 



ctfplot* Window: -5000 0 -10000 0 Scale: 1 micron Is 0.075 Inches (1905x) 

1 nv-and-move- 1 nv-20-0 




Figure 4.3 (merge inverter (move inverter 20 0)) 
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An item's dimensions are useful for placement operations. Another 
way to access an item is by labeling it. 
c. Point Operators 

Labels are used by simulation, routing and timing programs. L5 has 
a number of functions that manipulate or use an item's points. They are 
summarized in Table 4.7 below: (Crouch, 1983, pp. 11-14) 

TABLE 4,7 
POINT OPERATORS 



Function 


Arouments 


BgSC.llPA.Uin 


find 


<item> 

<point-name> 


get the first point in the item with 
the given name 


find-all 


<item> 

<point-name> 


return all the item's points with the 
given name 


find- 

attributes 


<item> 

<attributes> 


find all the item's points with given 
attributes as a subset of their 
original attributes 


match-that 


<thing> 

<list> 

<predicate> 
&opt1ona1 <tai1> 


give the list elements which satisfy 
a predicate relation with the given 
’thing’ 


unmark 


<ltem> 

<point> 


take the point off the item 


unmark- 

name 


<item> 

<name> 


delete points with the given name 
from the item 


unmark- 

attributes 


<item> 

<attributes> 


remove points whose attributes 
contain the given attributes as a 
subset 


unmark- 

attributes- 


<item> 

<attributes-list> 


discard points that contain any 
element of the given attributes list 



list 



TABLE 4.7 (CONTINUED) 
POINT OPERATORS 



Function Arguments 

contain <1tem> 



<ncme> 



Description 

prepend the given name to every 
point’s name in the item 



The following examples show how point operators work. The 



Inyoot-inoerter introduced in Section IV.5.2.B is again used here. This 
time the +5 Volt power point is extracted from the item: 



-> (find (loyont-inverter 4 t) ‘wdd)<CR> 

;; Find the first point named “vdd“ in a layout-inverter. Refer to 
;; the previous example for (layout-inverter 4 1). 

((udd) 8 -2 NM (power)) 

A more complex item,leyeot-eod, is shown below [Figure 4.4]: 

-> (layoat-and 4 4 t)<CR> 

;; Another MacPitts organelle. This one "ands" two inputs. Note 
;; that the organelle calls <symbol>Si 4 itself is 

;; <symbol>to- The list ( 1 4 6 8 9 10) shows the symbols. 

(0 -43 25 0 



(((ynd) 18-18 NM (pauier)) 
((odd) 8 -2 NM (paioer)) 
((ynd) 21 -41 NM (power)) 
((ini) 14-43NP (in)) 

((in2) 19-43NP (in)) 

((odd) 8 -25 NM (power)) ) 
(1 4 6 8 9 18) 

(symbol-call 18) ) 



Since this item has more than one +5 Volt power point, they can 
be extracted using the following procedure: 



-> (find-oil (loyoot-ond 4 4 t) 'odd)<CR> 

;; Find all points named "vdd“ in a layout-and item. 

(((odd) 8 -2 NM (power))((odd) 8 -25 NM (power))) 
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Figure 4.4 (lagout'*and 4 4 t) 



1 16 




-> (let 

((test-item 
'(0 0 3 4 

(((in) 2 3 NO (enternal top)) 

((udd) 1 1 NM (poiuer left river)) 

((out) 3 3 NP (enternai signai top)) ) 

(1 2 3) 

(sgmbol-call 3) ) ) ) 

(find-attributes test-item '(enternal top)) )<CR> 

;; Find all points with "externar and “top" as a subset of their 
;; attributes.12 This method uses attributes to find points. 

(((in) 2 3 NO (enternal top)) 

((out) 3 3 NP (enternal signal top)) ) 

After a point has been used it is sometimes desirable to remove it 

from the item. There are several functions that accomplish this. Here are 

two examples of how to remove one point. The first method requires that 

the entire point be specified as follows; 

-> (unmark 

(lagout-inuerter 4 t) 

'((gnd) 18-18 NM (pomer)) )<CR> 

;; Remove the point from the item. 

(8 -28 28 8 

(((udd) 8 -2 NM (pooler)) 

((ini) 14-28NP (in))) 

(1 4 6 7) 

(sgmbol-call 7) ) 

The second way to delete a point is to use its name: 



12 The attributes could be a list of lists instead of a list. In that case 
when find-attributes is applied the attributes parameter has to be a list 
of lists. If the points are of the form: 

((<name>) <x><yxlayer>( {(<attribute>*)} )) 

Then to use find-attributes: 

(find-attributes <item> ■((<attribute>A)...(<attribute>L))) 



-> (unmark-name (layout-inverter 4 t) ’vdd)<CR> 

;; Remove the named point from the item. 

(0 -20 20 0 

(((ini) 14-20NP (in)) 

((gnd) 18-10 NM (power)) ) 

(1 4 6 7) 

(symbol-call 7) ) 

More than one point can also be removed by either using a list of 
attributes. The first method removes points that have <?// the specified 
attributes as part of their attributes. In the next example any point with 
both an “ external " and " top “ attribute is deleted, as shown below: 

-> (let 

((test-item 
(0 0 3 4 

(((in) 2 3 NM ((eMternaD(top))) 

((udd) 1 1 NM ((power)(left)(river))) 

((out) 3 3 NP ((eHternal)(signal)(top))) ) 

(1 2 3) 

(symbol-call 3) ) ) ) 

(unmark-attributes test-item '((eHternal)(top))))<CR> 

;; Remove any points that have "extemar and “top" as part of 
;; their attributes.’^ 

(0 0 3 4 

((udd) 1 1 NM ((power)(left)(riuer-router))) 

(1 2 3) 

(symbol-call 3) ) 

The second method removes points that have any of the specified 
attributes as part of their attributes. Compare the following example, in 
which any point with either " left " or " top “ attributes is removed, with the 
one just presented: 



’3 As in find-attributes, the attributes can either be a list of atoms 
or a list of lists. 



"> (let 

((test-item 
'(0 0 3 4 

(((in) 2 3 NM ((eHternal)(top))) 

((udd) 1 I NM ((poiuer)(left)(riuer))) 

((out) 3 3 NP ((eHternal)(signal)(top))) ) 

(1 2 3) 

(symbol-call 3)) )) 

(unmark-attributes-list test-item '((left)(top))))<CR> 

;; Remove any points that have “1eft“ or “top" as part of their 
;; attributes. The river attribute refers to the river router'^ 

(0 0 3 4 nil (1 2 3)(sgmbol-call 3)) 

Once an item has been created, it may be desirable to give all its 
points a common name. By doing this, point functions that use a name as an 
argument to search for points will find all points with the common name. 

-> (contain (layout-and 4 4 t) *and-1)<CR> 

;; Prepend the name "and-1" to every point's name. 

(0 -43 25 0 

(((and-l gnd) 10-10 NM (pomer)) 

((and-1 udd) 0 -2 NM (pomer)) 

((and-1 gnd) 21 -41 NM (pomer)) 

((and-1 ini) 14-43NP(in)) 

((and-1 in2) 19 -43 NP (in)) 

((and-1 udd) 0 -25 NM (pomer)) ) 

(1 4 6 0 9 10) 

(sgmbol-call 10) ) 

Labels [points or marks] are useful as references to direct other 
functions. Notice how the next function, layout-flags'^, gives each of its 
points a " river ‘ attribute. These labeled points can then be used by the 
rioer function to connect them to other items. 



See Section IV.B.2.d. 

'5 This function is found in the MacPitts program flags.l. 



The next results, shown in Figure 4.5, are a set of four NMOS 
master-slave storage elements with load, write and read control lines. The 
labels in Figure 4.5 have been shifted in the positive x direction for 
legibility. Here are the four flags: 

->(layout-flags ‘(ini menie mini mae) Q 138)<CR> 

;; (layout-flags (<flag-name>*) <powerxflag-width>) 

;; <flag-width> :;= 

;; -> (flags-required-width (<flag-name>*)<power>)<CR> 
;; Instantiate four flags [storage elements). 

(-25 -97 293 145 



( 



((flag-iurite ini)) 7 -97 NP (riuer)) 
((nag-read ini)) 21 -97 NP (riuer)) 

((nag-load ini)) 62 -97 NP (riuer)) 

((flag-mrite menie)) 67 -97 NP (riuer)) 
((flag-read menie)) 81 -97 NP (riuer)) 
((flag-load menie)) 122 -97 NP (riuer)) 
((flag-mrite mini)) 127 -97 NP (riuer)) 



((flag-read mini)) 
((flag-load mini)) 
((flag-mrite moe)) 
((flag-read moe)) 
((flag-load moe)) 



1 41 -97 NP (riuer)) 
182 -97 NP (riuer)) 
187 -97 NP (riuer)) 
201 -97 NP (riuer)) 



242 -97 NP (riuer))) 

1234567891011 12 13 14 15 161 7) 
(sgmilol-call 17) ) 

In the item generated above, each point can be accessed by its 
name or by its attributes. In this case, all the points share a common riuer 
attribute, which indicates, that the riuer routing function will operate on 
them. 

Routing operations are among the operators that make effective 
use of points. In the following section the aforementioned riuer function, 
which connects two coordinate lists, is presented. 
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Figure 4.5 Oayoat-flags '(ini mania mini moa) 0 138) 
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d. River Router 

L5 has a simple, but useful river router with this syntax; 

(riuer <layer><width><slrelch>(<y left>*)(<y right>*)) 

<layer> :;r { NM I NO I NP I CM 

{ <width> I <stretch> I <y left> I <y right) } ;:= <number> 

The <stretch> is the amount -of extra reach desired on the right 
side of the river. The lists of left and right y coordinates are the connection 
"points". Both lists should contain the same quantity of numbers. The left 
coordinates are connected to their respective right coordinate: that is, <y 
left>N to <y right>M. The <width> is the desired width of the connecting runs. 

The results are easier to show than to explain, so here is an 
example and its plot (Figure 4.6): 

-> (riuer 'NM 3 10 '(1 8 17 26 37) '(5 17 29 41 57))<CR> 

;; Connect <y left)^ to <y right)^ 

(0 0 43 58 nil nil 

((reel NM 0 0 27 2)(rect NM 27 0 30 6) 

(reef NM 27 4 43 6) 

(rect NM 0 7 21 9 )(rect NM 21 7 24 18) 

(reel NM 21 16 43 18) 

(rect NM 0 16 15 18)(rect NM 15 16 18 30) 

(rect NM 15 28 43 30) 

(rect NM 0 25 9 27 )(rect NM 9 25 12 42) 

(rect NM 9 40 43 42) 

(rect NM 0 36 8 38)(rect NM 3 36 6 58) 

(rect NM 3 56 43 58))) 

Routing between the control unit and the data path section in 
NaePitts is done vv'ith riuer. In LBS, all the routing between the I/O pads 



Other layers such as CMF or CMS can be easily added by placing them 
into the second line of the river function in L5 [where the spacing between 
different runs is determined]. For example: 

(assoc (layer '((NM 3)(N0 3)(NP 2)(CM 3)(CMF 3)(CMS 3)))) 
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X 




Figure 4 6 (riiper ‘NM 3 10 *(1 8 17 26 37) ’(5 17 29 41 57)) 
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end the combinetionel logic unit elso utilize river The router cen be used 
by assigning an attribute such as (river) to an item's points. The points are 
obtained using this attribute and one of the functions discussed in Section 
IV.B.2.C.. The desired points' y coordinates are then extracted and passed as 
lists to river. 

A brief look has been taken at L5's data structures and operators; 
however, they can become untenable if a large collection of items have to be 
handled one by one. L5 resolves this problem by allowing abstraction of 
items into symbols. These symbols can in turn be used to form more complex 
items or symbols. At each level representational complexity is reduced, 
allowing L5's operators to operate efficiently. 



C. HIERARCHICAL REPRESENTATION 

The representation of knowledge or the structure of an organization in a 
hierarchical fashion is commonplace (Mead, 1980, p. 292); 

We know that human organizations use hierarchical structure to 
extract the greatest possible benefit from the daily activities of tens of 
thousands of individuals. We know that complex systems can be 
constructed by subdividing them into less complex systems, which are 
again subdivided, as many times as necessary, until the resulting systems 
are simple enough to construct easily .... The organization of real estate 
on the silicon surface dictates a hierarchical communication system for 
any devices that must support global communication. 

Within this hierarchical circuit structure, the Abstraction Principle, 
requires that items be created only once from scratch; recurring patterns 
should be factored out (MacLennan, 1983, p. 1 1) This is done in L5 with the 
macro def symbol. (Crouch, 1983, p. 16)(Cf. Ayres, 1983, p.20) 
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1. Defsumbols 

In order to save memory and time, L5 has a define symbol 
(defsymbol) macro which treats items in a fashion similar to a subroutine. 
The defsymbol macro has the following syntax: 

<defsymbol-name> 

-> (defsymbol <defsymbo1-name>(<arguments>)<L5 form>)<CR> 
<L5 form> { <11nco1n form> I <L1SP form> I <L5 form> }* 

When an item that has been defined as a defsymbol Is called with a 
set of arguments It Is saved as a symbol on the L5-symbol-list. Then, if 
It Is called again by another function with the same parameters, the L5- 
symbol-list Is searched for the symbol representing the item. The 
position of the symbol in the L5-symbol-list Is returned and placed In 
the colled-symbol-nomes field of the item. 

If the defsymbol has not been called with the given set of 
parameters, then a symbol corresponding to the defsymbol will be placed 
on the L5-symbol-list. 

There ore other effects of using a defsymbol that depend on whether 
the L5-symbol-list‘s value Is in-memory or on-disk. If It s set to in- 
memory then the item's tree Is saved as part of the symbol that Is 
placed on the L5-symbol-list. On the other hand. If It's set to on-disk, 
then the item’s tree Is not stored os port of the symbol; the tree Is 
converted to GIF and output to the L5-symbol-file. These two 
possibilities and their effects are summarized In Figure 4.7; 
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"L5-symtjol-storage 
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in-memory 
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save item description in the 
symbol's tree 



save the item's description as 



CIF in the L5-symbol-file 



Figure 4.7 L5-symbol-storage 



It is useful at this point to create a function to set the values of a 
few global variables. This is useful because during an interactive session 
the LS-sgmbol-list becomes very large; and, it also helps to be able to 
give global variables values the user typically uses. For example: 



-> (defnn start 0 

(setii — L5-sgmbol-list nil) 

(setq --LS-sgmbol-nnmber nil) 

(setq — L5-sgmbol-storage 'in>memarg) 

;; patom := put atom, outputs its arguments to the given port 
;; (it defaults to the screenl. 

(patam 'I Tba LS-sgmbol-list/number are nil. I) 

;; terpri := terminate printing. 

(terpri) 

(patom 'I The L5-sgmbol-storage is in-memorg. I) 
(terpri) )<CR> 

;; Whatever values the user desires could be set. For example: 

;; (minimum-feature-size! 150) 

;; (technology! 'cmos) 



A comparison is now made of the two ways to store symbols, 
a. in-memorg Storage 

Assuming that lincoln and L5 have been loaded into LISP, the global 
variables can be reset as follows: 



-> (start)<CR> 

;; Reset the symbol-list/number/storage. 

The L5-sgmbol-list/number are nil. 
The L5-sgmbol-storage is in-memorg. 



start 
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The storage location has been set to in-memory. A look at how a 

defsymbol works is now taken; 

-> (defsymbol buttiny-contact 0 
(merye 

(rect *NM 0 -6 4 0) 

(rect 'NO 0 -4 4 0) 

(rect 'NP 0-6 4 -3) 

(rect *NC 1-53-1)) )<CR> 

;; A butting-contact is one of L5's defsymbols. 
buttiny-contact 

-> (bottiny-contact)<CR> 

;; Create a butting-contact item. Notice it calls <symbol>i in the 
;; L5-symbol-list [itselfl. 

(0 -6 4 0 nil (1)(symbol-call 1)) 

What happened to all the layout information in the buttiny- 
contact? It has been placed on the L5-symbol-list. 

-> (L5-symbol-list)<CR> 

;; The L5-symbol-list only contains a symbol for butting-contact. 
;; symbol-ID := (butting-contact 4) 

;; symbol-nest-level := 1 

;; symbol-tree := ((rect NM 0 -6 4 0)...(rect NC 1 -5 3-1)) 

(((buttiny-contact 4) 0 -6 4 0 nil nil 1 
((rect NM 0 -6 4 0) 

(rect NO 0 -4 -4 0) 

(rect NP 0 -6 4 -3) 

(rect NC 1 -5 3 -1)))) 

A defsymbol can be retrieved as a function from the L5- 

symbol-list using the L5-item-to-proyram function using this syntax: 

(def <function-name> (lambda nil <L5 form>*)) 

-> (L5-item-to-proyram <item formxfunction-name>)<CR> 

<item form> ;:= { <item> I <defsymbol-name> } 
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A few caveats about the use of L5-item-to-program are in 



order here; 

• Avoid making the <function-name> ;= <defsymbo1-name>. The function 
that's generated replaces any existing function with the same name, 
specifically: an item created with a defsymbol definition would be 
replaced with a zero argument function with the offending name. 
Consequently, when the unsuspecting user attempts to use the defsymbol 
with arguments, the system will return errors. 

• Don't use on-disk storage. If a defsymbol is to be converted in this 
fashion, then the storage location must be in-memory. 

These ideas are best illustrated with an example of an item that 

has previouly been looked at, a (layout-inuerter 4 t); 

-> (L5-item-to-proyram 

(layout-inuerter 4 t) *inuert)<CR> 

;; Make the item (layout-inverter 4 1) into a function. 

(def inuert 
(lambda nil 
(merge 

(moue (diff-cut) 16 -16) 

(rect ‘NO 7 -18 16 -16) 

(rect ‘NP13 -20 15-14) 

(layout-pullup) 

(mark 'gnd 18-18 'NM ‘(pouier)) 

(mark ini 14-20 'NP (in)) 

(mark ‘odd 8 2 ‘NM '(pouier))))) 

This function is a specific instantiation of the original 

defsymbol. Notice that the defsymbol has arguments;^*^ 



’■7 The reader can take a look at a defsymbol's definition using the 
pretty print function. The output is a function that calls up two subsidiary 
functions, desymboll and defsgmbol2. These functions check to see if 
an item is already on the L5-symbol-list and if not, they add a new 
symbol to it. For example, try; -> (pp butting-contact) 
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-> (defsymbol layont-inuerter (ratio I mark?) 

(let 

((diffasioR 

(merye 

(raoue (diff-cut) 16 -16) 

(mark 'ynd 18-18 *NM (poiuer)) 

(cond 

((=> ratiol 4)(rect ND 7 -18 16 -16)) 

(t (rect ‘ND 7 -28 16 =16))))) 

(yote (rect ‘NP 13 -20 15 -14)) 

(mark 

(CORd 

(mark? (mark ‘ial 14-20 ‘NP ‘(ia))) 

(t (RUll-iteHi))))) 

(merye diffasioR yate mark (layout-pullup))))<CR> 

;; The desymbol macro returns a name. 

layout-iRuerter 

If many large items are placed on the L5-symbol-list and all 
their trees are also placed there, the list quickly becomes unwieldy. An 
alternative is to keep all the other information in the L5-symbol-list, 
convert the item’s tree to CIF and place the CIF in the L5-symbol-file. 
b. OR-disk Storage 

This storage mode reduces the L5-symbol-lists size by changing 
the item’s tree to CIF. It is useful when items don’t need to be retrieved 
from the L5-symbol-list with their trees (for example, the L5-item-to- 
proyram function will only create a program out of a symbol if its tree is 
on the L5-symbol-list; similary, the Caesar conversion routines {Section 
IV.C.3} also require iR-memory storage]. 

An example can be examined after resetting all the global 
variables using the start function. First the L5-symbol-storaye is set 
to OR-disk and the effect compared with the results of Section IV.C.I.a. 
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-> (st«rt)<CR> 

The L5-sgmbol-list/namber ere nil. 

The L5-sgmbol-storage is in-memorg 

-> CL5-sgmbol-storagei *an-disk)<CR> 

;; Set the symbol storage location to on-disk 

an-disk 

-> (butting-cantact)<CR> 

;; The butting contact item looks the same as before. 

(0 -6 4 0 nil (1)(sgmbal-call I)) 

-> (L5-sgmbal-list)<CR> 

;; Although the butting-contact item is the same the <symbol> no 
;; longer has a tree in it. Compare to the L5-symbol-list in the 
;; previous section. 

(((batting-cantact 4) 0 -6 4 0 nil nil I)) 

In this case the L5-symbol-list contains only one symbol. If there 
are several symbols in it, then they can be individually retrieved in item 
form as follows: 

<item> -> (create-called-sgnibal-iteni <position>)<CR> 
<position> ::= <integer> 

, Therefore, continuing with the above example: 

-> (create-called-sgmbnl-item 1)<CR> 

;; The item that is returned has a symbol-call tree. This means 
;; that the item has been output as CIF^s and is referred to as CIF 
;; symbol 1. 

(0 -6 4 0 nil (1) (sgmbal-call 1)) 

This is exactly the result that evaluating (batting-cantact) 
gave. The price gained in speed and storage is the less descriptive format. 
However, the item has been converted to CIF. 



18 See Footnote 8 of this chapter. Section IV.C.2 covers this in more 
detail. 
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2. Cl£ 

When the on-disk storage mode is used, an item’s tree is sent to the 

LS-sgmbol-file as CIF. A brief look is now taken at the CIF result from 

the previous example: 

-> (L5-sgmbol-file)<CR> 

/tmp/L5sgm20374 

-> (oMoc cat /tmp/L5sgm20374|<CR> 

;; exec allows UNIX® functions to be performed from LISP. In this 
;; case the contents of the L5-symbol-file are concatenated to 
;; the terminal. The following is CIF output. CIF uses ” ( " and “ ) ” 
;; for comments. 

OS 1; 

(define <CIF symbob named 1); 

(name: butting-contact); 

(CIF comments are not printed out); 

L NM; B L 1000 OP 1500 G 500, -750; 

(since this was output with 250 centimicrons = lambda); 
(all the units must be divided by this amount); 

(CIF defines its rectangles like L5 does its boxes:); 

( <layer><length><width><x,;eM*r><yceftt*r>); 

( (box ’NM 4 6 2 -3) ); 

L NO; 0 L 1000 ID 1000 C 500, -500; 

( (box ’ND 4 4 2 -2) ); 

L NP; 0 L 1000 ID 750 C 500, -1125; 

( (box ’NM 4 3 2 -3) ); 

L NC; 0 L 500 01 1000 C 500, -750; 

( (box ’NM 2 4 2 -3) ); 

OF; 

(end <CIF symbol>i‘s definition); 

The function that L5 uses to create CIF has the following format: 
<file>.cif ::= -> (cifout {('l<item>H(']<file>H"<title>"})<CR> 
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A few comments on using this function ore: 

• The number of centi-}i/\ should be set using minimum-feature- 
sizei before outputting CIF. If an item was created with on-disk storage, 
then the CIF has already been made at whatever minimum-feature- 
size the system is currently using. Therefore, functions such as cifplot 
must be given the scale to use if it is not 2.0 centi-ji/X; otherwise, 
plotting errors will occur. 

• The title appears as a CIF comment. For example, if the title is: 

"butting-contact”, 

then the CIF comment line is: 

(Title : butting-contact); 

• If points or marks are to appear as CIF they should have the enternal 
attribute. The conventional “ 94 “ CIF user extension for labels has been 
added as a default option to the function cifout-enternal-name in L5.1 
to enable the standard cifplot program to plot marks and points. (Carlson, 
1984, p.78) 

Although L5 items can be transformed into CIF, the inverse function is 
not directly implemented in L5. In order to accomplish this, Caesar format 
is used. 

3. Caesar 

L5 Is used to design circuits in a procedurally oriented approach. 
Another, and perhaps the most widely used VLSI design methodology, is 
graphical. L5 provides access to the interactive graphical editor Caesar. At 
the present time, the Caesar editor can be invoked from the L5 environment. 
Conversely, Caesar files can be changed to L5 format. Figure 4.8 shows the 
different ways to get from one format to the other: 
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/->-caesar— 

.ca L5 



casav6' 

cif2ca<5 



7 

cifout 



V-CIF-^ 



Figure 4.8 Caesar, L5 and CIF Conversions 
There are several functions associated with the Caesar editor. Table 
4.8 gives a synopsis (Crouch, 1983, pp. 17-18): 

TABLE 4.8 
CAESAR FUNCTIONS 

Function Arouments^ o Description 

caesar <itemxfi1e> Converts an <item> into Caesar format, the 

Caesar editor is invoked and the results of 
the session are saved in the <file> as items. 



displan <item> Displays the <1tem> in Caesar without 

generating any L5 code afterwards. 

caoat <itemxfi1e> Outputs the <item> in Caesar format to 

<file>.ca 



cain <fi1e> 



Reads in a Caesar formatted file and 
converts it to L5 code. 



casaue <caesarfile> Converts a <caesar fi1e> into L5 code and 

<L5 file> saves the result in <L5 file>. Each Caesar 

symbol is made into an L5 defsymboi. 



This is a Berkeley CAD conversion program from CIF to Caesar format. 
A minor problem with this present scheme is that Caesar evolved into the 
more versatile Magic system. The routines need to be modified to use Magic 
format instead of Caesar format. 

20 All of these functions are fexprs, therefore, none of the arguments are 
quoted. 
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TABLE 4.8 

CAESAR FUNCTIONS (CONTINUED) 

Function Ar guments DescrlDtlon 

cadef <caesarfile> Places each Caesar symbol on the 

LS-symbol-list. 

4. Summaru 

= This chapter has covered the significant features of L5. Its 
hierarchical style is well suited for writing procedures which manipulate 
lower level primitives. These basic building blocks can be designed on a 
graphical layout editor and then converted into L5 programs. 

At the present time L5 uses the Caesar editor. In the future a routine 
should be implemented to use the more versatile Magic editor. 
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V. TQP.L AND PREPASS.L: THE TQP-LEVEL 



The reader has seen how a group of LISP object files can be loaded 
together to create a LISP environment’. This chapter shows how a top-level 
function is used to make an environment accessible with parameters. In 
other words, the environment will be invoked just like other UNIX® 
commands. Two programs that contain top-level functions are top.l (LBS) and 
prepass.l [MacPittsl. In addition, these programs contain the "compilers” for 
LBS and MacPitts. A look at these top-level programs brings to light major 
differences and similarities between LBS and MacPitts. 

A. THE TOP-LEVEL 

1. Franz Lisp's Default Top-Level 

A top-level function creates the prompt-read-eval-print loop.The 
user can call the top-level function and can create a prompt-read-eval-print 
loop with different characteristics. To do this, the user defines a new top- 
level function and types (reset) to run it. (Foderado, 1983, p. 13- 
iKWilensky, 1984, p.l38) 

When the imperative command lisp is given to UNIX®, the interpreter 
is brought into action with its default top-level: franz-top-leuel^. This 
occurs because the variable top-level is bound to franz-top-leuel. 



’ See the discussion in Chapter II Section B.2.b. 
2 Defined in /usr/lib/1isp/top1eve1.1 
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Some of the actions taken by this default top-level are (Foderado, 
1983, Appendix C.2)(Wilensky, 1984, p. 348): 

• Print out: Franz Lisp Opus 38.69 

• Load .lisprc from the user's HOME directory. 

• Enter a prompt-read-eval -print loop. Each time through, before the 
prompt is printed, the value of user-top-leuel is checked. If it has been 
bound, then its value will be funcalled. This allows the user to enter a 
different top-level for the interpreter. Handle errors, interrupts, etc.. 

2. Example Top-level 

At this point, it's useful to use a simple makefile and top-level file 
to examine the ideas involved in more detail. The makefile is as follows: 

chip: L5.0 defstructs.o top.o creator.o 
(echo '\ 

(euol-uihen (euol)\ 

(sstatus translink on)^\ 

(fasi 'lincoln)\ 

(fast *L5)\ 

(fasI ‘defstructs)\ 

(fasI 'top)\ 

(fasi ‘creator)\ 

(setq user-top-leuel 'chip-top-leuel)\ 

(signal 2 'chip-interrupt-handler)\ 

(setq option-list '(stat obj cif))\ 
(minimum-feature-size! 150)\ 

(dumplisp chip)\ 

(enit))* i lisp 



2 Makes LISP transfer of control to compiled functions fast (Wilensky, 
1984, p. 284). This may be a disadvantage if debugging and tracing is to be 
done within this dumplisp environment, since the trace and debug 
functions will not work. If the primary intent is to debug code then use: 

(sstatus translink nil) 



The top-level file, top.l, is composed of several LISP functions. The 
first, chip-top-leuel, performs a check of the arguments used when 
invoking "chip". If there are no arguments then the "chip" dumplisp 
environment is called up. If there are arguments, then these are passed on to 
the chip-compiler function. The user should note that chip-top-leuel 
was set to be the top-level function in the example's makefile above. 

In other words, the "chip" dumplisp environment has a function, chip- 
top-leuel, which handles the arguments placed in the command line when 
"chip" is invoked. Notice that if no arguments are given, then a message is 
printed out and the user is placed into the " chip " dumplisp environment. 
This feature can be used for debugging purposes [See Footnote 3 of this 
chapter]. A look at this function follows; 

(defun chip-top-leuel 0 

;; If “chip" is invoked without any arguments: 

(cond ((»1 (argu)) 

;; (argv) gives the number of elements on the command 
;; line that invoked this LISP. So, if the user types; 

;; % chip <argumentt><argument 2 ><argument 3 > 

;; then (argv) := 4 

(patom 

'usage: chip <fllename> [<optlons>]') 

;; (patom <expression>[<port: default to screen>j) 
;; print out the expression; 

;; usage: chip <filename> [<options>] 

;; The " [ ” and " ] " indicate an optional argument. 

(terpr) 

;; (terpr) or (terpri) terminates printing. 

(setq user-top-leuel 0) 

;; The variable user-top-level is set to nil, but 
;; notice that in the makefile it was set to chip 
;; top-level. Therefore, if chip is called up 
;; without arguments, then chip-top-level calls 
;; up the “ chip “ dumplisp environment 
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;; and gives control to franz-top-level, e.g.: 

;; ^ chip 

;; usage: chip <filename>(<options>] 

;; (Return to top level) 

;; -> 

(signal 2 (function sys:int-seru)) 

;; (signal <numberxfunction>) 

;; The number 2 represents an interrupt signal 
;; and sys;int-serv is the LISP default function 
;; that handles interrupts (See I.B.I.c]. (Wilensky, 
;; 1984, pp. 269 & 355)(Foderado, 1983, p. 6-7) 
(reset) 

;; If "chip” is invoked with arguments; 

(t 

(chip-compiler 

;; (chip-compiler <file-name> (<options>)) 

(mapcar 

;; The mapping function mapcar retrieves the 
;; arguments typed in the command line, e.g.: 
;; ^ chip multiplier cif Ob j 

;; then, 

;; (mapcar (lambda (x)(argv x))(l 2 3)) 

;; returns; 

;; (multiplier cif obj) 

(lambda (inden)(argu indeu)) 

;; (argv <index-number>) 

;; returns the indexed argument on the 
;; command line, e.g. If, 

;; ^ chip adder cif 

;; then, 

;; (argv 1) ;= adder and (argv 2) := cif 
;; -> (argv 0) 

;; chip 

;; and (argv) gives the total number of 
;; arguments on the command line: 3 

(couat (1- (argu))) ) ) ) ) 

;; (count <integer>) 

;; make a list of integers up to the given 
;; one. 
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;; -> (count 5) 

;; (12 3 45) 

(euit) ) 

The next function is set up in the makefile to handle interrupts. When 
an iterrupt is received it prints out "clijp-interriipt:", the signal number 
and then exits the "chip” dumplisp environment. Here is the code: 

(defun chip-interrupt-handler (signal-number) 

;; This is used in the makefile as the function that 
;; handles interrupts (2), floating exceptions (8), 

;; alarms (14) and hang-ups (1). (Wilensky, 1984, p. 270) 

(patom " chip-interrupt: *) 

(patom signal-number) 

(terpr) 

(euit)) ) 

The previous functions allowed the user to invoke the "chip" dumplisp 
environment as a UNIX® command. The following function is used within the 
"chip" dumplisp environment to pass arguments to the chip-compiler 
function: 



(def chip 

;; The niambda function format takes many arguments, 

;; they are unevaluated and bound as a list to the 
;; function's single parameter. For example: 

;; -> (chip adder cif obj) 

;; then args := (chip adder cif obj) 

(alamhda (args) 

;; (chip <fi1ename> (<option>*l) 

;; <option> ::= {nostat I noobj I nocif I mag} 

;; <default option> ::= stat obj cif 
Uhip-compiler args) ) ) 

The next function coordinates other programs in order to produce the 
different types of output. It first uses the process-option function to set 
the global variable, option-list, to the options that have been input. Then 



139 



it calls on other programs to process the options and place the outputs in 
appropriately labeled files. 

(defun chip-compiler (args) 

;; (chip-compiler ‘(<fi1ename>(<option>*))) 

(cond 

((not (null args)) 

;; If there are arguments then find the options using 
;; the process-option function. This will place all 
;; requested options along with other defaults which 
;; were not inhibited on the option-list. 

(mapcar 'process-option (cdr argst) 

(prog (in-file stat-file mag-file obj-file 
out-file inport statport magport 
objport netlist output) 

;; After declaring all the prog's local variables, 

;; set the filenames [e.g., <filename>.chip, 

;; <filename>.stat, etc..]. 

(setq in-file (concat (car args) '.chip) 
(setq stat-file (concat (car args) '.stat) 
(setq mag-file (concat (car args) '.mag) 
(setq obJ-file (concat (car args) '.obj) 
(cond 

;; If the in-file exists, then take the following 
;; actions. 

((probef in-file) 

(setq inport (infile in-file)) 

(setq statport (fileopen stat-file 'ui)) 
(setq netlist 

(converter (read inport) stat-port)) 
(cond 

. ;; If "obj" is in the option list, then . . . 

((member 'obj option-list) 

{ & other function calls to other 
subprograms as required to make 
the chip) ] ) 

The option-list has certain default values set in the makefile. The 
user can inhibit them by placing "no" in front of them (e.g. nostat]. On the 
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other hand, there may be other options, besides the default values, which 
the user can input. The following function examines the options the user has 
input and updates the option-list as required; 

(defun process-option (option) 

(cond 

((not (atom? option)) 

(morning 'Option not atom')) 

;; Options must be atoms. 

((and (> (length (enplode option)) 2) 

(equal *n (car (enplode option))) 

(equal 'o (cadr (enplode option))) ) 

;; Is the option more than two letters long and its 
;; first tv/o letters an "n" and “o" (the option is of the 
;; form: noXXXl? Explode separates an atom into the 
;; characters that compose it (implode is its dual). 

(cond 

;; Is the rest of the option li.e. excluding the ” no "1 
;; in the option list? 

((member? 

(implode (cddr (enplode option))) 
option-list ) 

;; Drop the option from the option-list. 

(setq option-list 

;; Remove the indexed element from the 
;; option-list. 

(nthdrop 

;; Find the index of the option without the 
;; “ no " in the option-list. 

(iota 

(implode (cddr (enplode option))) 
option-list ) 
option-list ) ) ) ) 

;; Otherwise, if the option is not of the form noXXX, 

;; then add it to the option list. 

(t (cond ((not (member? option option-list)) 
(setq 

option-list 

(cons option option-list) )))))) 
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Both LBS and MacPitts have top-level functions similar to these. The 
major difference between the two programs is that LBS generates 
combinational logic circuits, whereas MacPitts has a control and data-path 
paradigm. A look at their compilers illustrates their differences. 

B. LBS COMPILER 

LBS accepts a file with LISP boolean forms as its input. These boolean 
forms have the following syntax: 

TABLE 5.1 
LBS SYNTAX 

Cateooru Syntax 

<LBS program> C<bform>+) 

<bform> ::= { (name <name>) I (setq <namexbform>) I 

(oot <namexbform>) I (nor <bform>*) I 
(or <bform>*) I (and <bform>*) I 
(not <bform>*) I (nor <bform>*) 

So for example, an LBS program might consist of the following lines: 

((setq load (nor (and (not ini) in2 clocki) in3) 
(out outi (nor (nand ini clock2) in4 load)) ) 

If a <name> is used as the first argument of a setq or an out it can be 
used in other <bform>s. Otherwise, the other <name>s are assumed to be 
inputs. The input file is parsed and converted into an intermediate “obj" 
format by bool-to-straps [located in extract.il. This is a connectivity list 
that is used to generate the Weinberger array implementation of the boolean 



^ Of course, bform is implemented as a defstruct. 
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expressions. This "obj" format is then used by layout-cmos-uiein [called 

by layoat-chip] or layout-inside [used in the Caesar section] to create 

the array. These ideas can be seen in the implementation of IBS's compiler. 

The Ibs-compiler function assumes that an. Ibs-top-leuel, Ibs- 

interrupt-handler and lbs function are available [See Section V.A]. IBS's 

compiler has the following format: 

(defun Ibs-compiler (arys) 

(cond 

;; If the arguments aren’t empty, then process them. 

((not (null arys)) 

(mapcar 'process-option (cdr arys) ) 

(proy 

;; Define local variables. 

(in-file stat-file caes-file obj-file out-file 
inport statport caesport objport bs chip ) 
(setq in-file (concat (car arys) '.lbs)) 

(setq stat-file (concat (car arys) '.stat)) 
(setq caes-file (concat (car arys) '.ca)) 

(setq obj-file (concat (car arys) '.obj)) 

(setq out-file (car arys)) 

;; Check that the input file is not empty and then pro- 
;; proceed to process the input file. 

(cond 

;; Probe the input file to see if it has anything in it. 

;; If it’s not empty then turn it into the in port. 

((probef in-file) 

(setq inport (infile in-file)) 

(setq statport (fileopen stat-file 'm)) 

;;The boolean input format is converted to a 
;; format showing connectivity and logical 
;; relationships. 

(setq 

bs 

(bool-to-straps (read inport) statport) ) 

;; Check the options and produce the ones desired. 

(cond 

;; Produce the intermediate "obj" format. 
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((member 'obj option-list) 

(setq objport (fileopen obj-file *ui)) 
(pp-form bs objport) 

(terpr objport) 

(close objport) 

(messoge-number-7) ) 

;; Produce Caesar format output. 

((member ‘hca option-list) 
(message-number-5) 

(setq caesport (fileopen caes-file ‘ui)) 
;; Create the Weinberger array. 

(setq 

chip 

(lagout-inside 

bs 

(car args) 
caesport) ) 

;; Create CIF format output. 

(cond 

((null chip)(message-number-4)) 

(t (cifout chip out-file out-file) 
(message-number-6) ) ) ) 

;; Create CIF format output. 

((member ’cif option-list) 
(message-number-1 ) 

;; Build a Weinberger array then route it to the 
;; I/O pads. 

(setq chip (lagout-chip bs)) 

(cond 

((null chip)(message-number-4)) 

(t (cifout chip out-file out-file) 
(message-number-2) ) ) ) ) 

;; Make a simulation file. 

(cond 

((member ‘sim option-list) 

(sim bs out-file)))) 

(t (message-number-3 in-file)) ) 

(return) ) ) ) ) 
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LBS has a simple architecture based on implementing combinational logic 
circuits in CMOS. MacPitts is a larger program with many more possibilities. 



C. MACPITTS5 COMPILER 



The increase in complexity from LBS to MacPitts can easily be seen in the 
syntax used by the latter program. A glance through MacPitfs BNP shows 
that it incorporates concepts such as: function, macro, port [n-bit datal, 
signal (t or f data], register [datapath storage], flag [signal storage], 
organelle [functional unit], test [e.g., = or =0], etc.. MacPitts, unlike LBS, 
requires that I/O pads be specifically declared [that’s why <pin-number>s 
are used to specify their location]. Again it should be noted that most of 
these ideas are implemented as defstructs.^ Skim through the BNP to gain 
a feeling for MacPitts' syntax; 



Categ ory 

<MacPitts 
program> ;;= 

<eval> 



TABLE 5.2 

MACPITTS SYNTAX 
Syntax 

(program <program-namexword-size> 

(<eval> I <def> I <always> I <process>}'^) 

(eual [compile I simulate I both} <LISP form>) 



<def> :;= (def <pin-number> 

{ pouier I ground I phia I phib I phic}) 

<def> (def <register-name> register) 



5 Only a brief description is given here of MacPitts. The reader should 
consult Southard [RVLI-3], 1983, pp. 1-33 and Siskind, 1981, pp. 1-18. 

6 This will be covered in more detail in Chapter VI. 



145 



TABLE 5.2 (CONTINUED) 
MACPITTS SYNTAX 



Caisgiiry 


Syidax 


<def> ;:= 


(def <port-name> port {input 1 output I 

tristate I i/o} (<pin-number>+)) 


<def> ::= 


(def <port-name> port internal) I 


<def> :;= 


(def <f1ag-name> flag) 


<def> ::= 


(def <slgna1-name> signal {input 1 

output 1 tri-state 1 i/o} <pin-number>) 


<def> :;= 


(def <signa1-name> signal internal) 


<def> ::= 


(def <constant-name> constant <form>) 


^def> ::= 


(def <organe11e-name> organelle 

<*contro1-11nes><*parametersx*test-lines> 
<resu1t?xGEN formxSIM form>) 


<def> ::= 


(def <function-name> function 

<organel1e-name> ({integer I boolean}'^) 
(<control-1ine>*)(<parameter>+)<INT form>+) 


<def> ::= 


(def <test-name> test <organel1e-name> 

({integer 1 boolean}'^)(<contro1-1ine>*) 
(<parameter>+)<test-linexlNT form>) 


<def> ::= 


(def <macro-name> macro {single I list) 

<LISP form>+) 


<p1n-number> ;:= 


<1ntegen 


<resuH?> :;= 


{ges 1 no} 


<always> ::= 


(aluiags <form>^) 


<process> ;:= 


(process <process-name> 

<stack-depth>{<1abe1> I <form>}*) I <macro> 


<stack-depth> ;:= 


<integer> 


<label> 


<symbo1> 
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TABLE 5.2 (CONTINUED) 
MACPITTS SYNTAX 


CateQoru 


Syniaii 


<form> ::= 


<integer> | “<character>" I <constant-name> I 
<reg1ster-name> I <port-name> I 
(go <form>) I 
(call <form>) 1 
(return) I 
(par <form>*) 1 
(if <form><formxform>) 1 
(cond {(<condUion><form>+)}+) I 
(setq <register-namexform>) 1 
(setq <port-namexform>) I 
(setq <signal-namexcondition>) I 
(<function-namexformula>+) I 




<macro> 


<macro> ::= 


(macro <macro-name>{single I list} 

<LISP form>+) 


<organe11e> :;= 


(organelle <organe11e-name> 
<^control-lines><^parametersx'^test-lines> 

<result?x6EN formxSIM form>) 


<function> ::= 


(function <function-name> <organelle-name> 

({integer I boolean}^) 

(<control-line>*)(<parameter>+)<INT form>+) 


<test> ::= 


(test <test-namexorgane11e-name> 

({integer 1 boolean}'^)(<contro1-1ine>*) 
(<parameter>+)<test-linexlNT form>) 


<condition> ;:= 


1 1 () 1 <signa 1 -nam 0 > 1 (and <condit1on>+) I 

(or <condition>'^) I (not <condition>) I 
(nor <condition>+) I (nand <cond1tion>+) I 
(nor <condition>+) I (equ <condition>+) I 
(bit <bit^>{<integer>|<integer form>}) I 
(setq <signal-namexcondUion>) 1 
(<test-namexform>+) I 
<macro> 
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TABLE 5.2 (CONTINUED) 
MACPITTS SYNTAX 



CateQorii Su ntax 

<???-name> ::= <symbol> 

The increased syntactical complexity is handled by functions in prepass.l 
that parse through the input forms. They can be divided into three major 
categories; functions that fetch something, those that manipulate data, and 
those that expand forms. They are used in conjunction with other programs 
in MacPitts and the defstruct macro to generate an intermediate “obj" 
description"^. This "obj" code can then be implemented in a controller and 
data path structure. The functions have the following syntax and in general 
their names are an indication of what they do: 

TABLE 5.3 



PREPASS.L FUNCTION SYNTAX 

Function SynM 

get-<x> 

<x> { source I library I object I program-name I 

program-tail I uiord-length I definitions I 
sources I sources-from-form-list I 
sources-from-form I destinations I 
destinations-from-component-list I 
destinations-from-form-list I 
destinations-from-form I 
labels-from-component-list I 
labels-from-form-list } 



This format is more complex than LBS's “obj" code. MacPitts "obj" 
format can be broken up into five sections; definitions, flags, data-path, 
control and pins. LBS only has a control section. 
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TABLE 5.3 

PREPASS.L FUNCTION SYNTAX 
Function Synlflii 

process-<y> 

<y> ::= { <z> I definitions I definition I control-line I 

paroroeter I test-line } 

<2> <2Z>-definition 

<22> { pouper I ground I phia I phib I phic I 

register I flag I signal I port I macro I constant I 
organelle I function I test } 

eKpand-<VV> 

<YY> { process I macro I form-list I form I 

component-list I component } 

A quick look is now taken at MacPitts' compiler. It works in a fashion 

similar to the LBS compiler. First, the input forms are converted to “obj“ 

format, and then this object code is transformed into the requested options. 

Here is the compiler function: 

(defun macpitts-compiier (operands) 

(prog (file-name file object obj item) 

;; ptime gives run and garbage collection times. 

(setq initiai-ptime (ptime)) 

;; The number of garbage collections that occurred. 

(setq initiai-gccount $gccount$) 

;; If the operands are null or atoms then return to the 
;; franz-lisp top level. 

(cond ((or (not (list? operands)) 

(null operands) 

(not (atom? (car operands)))) 

(patom "usage: (macpitts <filename> 
(<options>])*) 

(terpr) 

(return ()))) 

(setq file-name (car operands)) 

;; Set the option-list to the requested and uninhibited 
;; default settings. 
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(mapcar 'process-option (cdr operands)) 
(statistic (concat "for project * file-name)) 
(statistic (concat "options: " 

(slash 

(enplode option-list) 

■ ■ 

(function concat) ) ) ) 

;; Set the process parameters to 5|i or 4vi. Note that 
;; MacPitts' makefile defaults to 250 centi-|i/\. 

(cond 

((member? '5u option-list) 
(minimum-feature-size! 250))) 

(cond 

((member? '4u option-list) 
(minimum-feature-sizel 200))) 

;; Is interpreter output one of the options? 

(cond 

((member? 'int option-list) 

(cond 

((null (catch (Interpret file-name) note)) 
(return ()))))) 

;; Is GIF or object format desired? 

(cond 

((or (member? 'obj option-list) 

(member? 'cif option-list) ) 

(setq object (get-object file-name)) ) 

(t (return t)) ) 

;; If nothing is generated up to now, exit. 

(cond ((null object) (return ()))) 

;; Output data-path statistics. 

(statistic (concat "Data-path has " 

(length 

(object-data-path object) ) 

" Units")) 

;; Is object code desired? 

(cond 

((member? 'obj option-list) 

(herald "Outpnting .obj file") 

;; Object code is made up of defs, flags, data-path, 
;; control and pins. 



150 



(setq obj 
(make-object 
(purge-library 

(object-definitions object) ) 
(object-flags object) 

(object-data-path object) 
(object-control object) 

(object-pins object) ) ) 

(setq file 

(outfile (concat file-name ".obj")) ) 
(pp-form obj file) 

(close file) ) ) 

;; Was CIF desired? 

(cond 

((member? ‘cif option-list) 

(setq item 

(catch (layout-object object) note) ) 

(cond ((null item)(return ())) ) 

(herald "Outputing .cif file”) 

(cifout item file-name file-name) ) ) 
(statistic (concat "Memory used - ” 

(/ (memory) 1024) ”K")) 

(statistic (concat 

'Compilation took ' 

(quotient 

(- (car (ptime))(car initial-ptime)) 

3600.0 ) ” CPU minutes” ) ) 

(statistic (concat 

"Garbage collection took ” 

(quotient 

(- (cadr (ptime))(cadr initial-ptime)) 
3600.0 ) ” CPU minutes” ) ) 

(statistic (concat 
"For a total of ” 

(- $gccount$ initial-gccount) 

” garbage collections”) ) 

(return t) ) ) 

In summary, a bird's eye view of IBS's and MacPitts' compilers shows the 
relative differences between the two programs. MacPitts has a more 



extensive syntax which requires more parsing of input code. Though they 
differ in complexity, these programs share many common features. They 
doth use a top-level function with an interrupt handler and option process to 
access a dumped lisp environment created with a makefile. After parsing 
through their input forms, they generate an intermediate object format. And 
finally, both use L5; and, all their data types are handled by the defstruct 
facility (including many of their inputs). 
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VI. ORGANELLES 



Chapter V contains MacPitts' syntax and its top-level function. MacPitts’ 
BNF allows the user to define functions, macros, tests and organelles and 
use them when writing a MacPitts program. Alternatively, the user can 
modify the organelles.l and library programs and remake MacPitts. In this 
fashion the new operators become part of MacPitts' syntax. 

A. OVERVIEW 

Before showing an example of the changes that are made in MacPitts to 
change its syntax, the relationships among some of its programs and 
functions need to be pointed out. When the user inputs a <MacPitts program>, 
the compiler (located in prepass.l] parses through the <MacPitts form>s. The 
program uses its get-<x>, process-<y> and eHpand-<yy>> functions to 
process <definition>s; evaluate <eval>s; expand <macro>s; and, obtain 
<source>s, <destination>s and <label>s. This is done by using list selectors 
to disassemble the <MacPitts program> while checking the syntactic labels 
that were used. For example, the words def, ground, process, macro, 
function, etc., all trigger the use of the process-definition function. 
The eual and process labels are treated separately. The functions used 
during the parsing process to obtain <definition>s from the input are shown 
below: 



’ Refer to Section V.C. 
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— ^get-defin1t1ons^ 

/ * ^ 

^aef> <eval> <pr 






<def> <eval> <process> 

/ i \ 

process-definitions make-eval-definition nnake-process-defimtion 



4 



process-<ZZ>-definition 









make-<ZZ>-definit1on 

Figure 6.1 Prepass Function Flow 

Once the definitions have been obtained and processed, the <f1ag>s, <data 
path>, <contro1>, <pin>s and <sequencer>s are eKtmcted (functions located 
in extract.!] from them . The <control>, <f)ag> and <data path> elements are 
framed (layout functions in frame.l] together from the results of the 
doto-path, controller, and flogs generators. A separate portion of 
MacPitts (general.lj contains general query and lookup functions used by 
the extractor and data-path generator. 

The physical layout descriptions, organelles, are in two sections: a 
compiled portion and a non-compiled program called a library. The data- 
path creator uses the compiled organelles and the extractor uses the library. 

The overall program hierarchy is sketched below: 

prepass. 1 



/ \ 

frame.l general. 1— extract. 1 
/ I \ I I 



flags.l control. 1 data-path.l library 



organelles.l 

Figure 6.2 NacPitts Program Hierarchy 



154 



Prepass.l is coordinates the conversion of the <MacPitts program) to a 
layout with its get-object function. This operator uses subsidiary 
programs (primarily extract.11 to produce an intermediate result, an " ,obj " 
file, which can then instantiated into the silicon mask level by layout 
functions [in flags.1, control.1 and data-path.ll. This object file is a 
defstruct with the following definition: 

(defstruct object 

(definitions flogs doto-poth control pins)) 

A quick look is now taken at the names of the major functional 
categories in prepass.l and its helper programs. Skimming through the 
function names provides a “ feeling " for MacPitts. The most common 
operators are summarized by program in Table 6.1. 

TABLE 6.1 

MACPITTS PROGRAM FUNCTION SUMMARY 
Program Function Name Format 

prepass.l get-<x>, process-<y>, enpond-<zz> 

extract.1 entroct-<A> 

<A> { component-list I process I form I atom I 

list I string I finnum I register I flag I port I 
signal I label 1 go I call I return 1 etc. } 

frame! layout-<5> 

<B> ;.= { object I skeleton 1 uiing I net I pins I 
pouier-ring} 

control.1 layout-<C> 

<C> ;:= { control 1 driver 1 mpn 1 register I 
uieinberger-<D> 1 etc. } 

<D> { gates 1 nor 1 nor-inport I nor-gnd-line I 

etc. } 

data-path.1 loyout-<E> 

<E> { data-path I buses 1 unit I organelle 1 etc. } 
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TABLE 6.1 (CONTINUED) 

MACPITTS PROGRAM FUNCTION SUMMARY 

Prograni Function Name Format 

flags.1 layout-<F> 

<F> { flags I flags-{ power I clock} I etc. } 

general.! is-<G>? 

<G> ;;= { register I flag I port I signal I macro I func- 
tion I test I label I etc. } 
lookup-<H> 

<H> ;:= { macro I constant I signal I port I word- 

length I sequencer I label I function I test I 
organelle I power-pin# I etc.} 

library <definit1on> {<macro> 1 <function> I <test> I <organelle>} 

organelles! lagout-<H>-organelle^ 

<H> { inuerter I nand I and I nor I nor 11+1 etc.} 

The names, to a large degree, convey their function's purpose. For 
example, lagout-data-path creates the L5 code for this portion of the 
chip. The library has many Instantiations of the definition^ defstruct. 
Examining this long structure generator [Figure 6.3] reveals that much of 
MacPitts syntax Is data: 

In particular, note that an <organelle>, <macro>, <funct1on> or <test> are 
all definition cases. The library Is a big list with parameters for specific 



2 lagout-<H>-organelle is the L5 item that will be implemented in the 
circuit, whereas, logout-<K> is a function that lays out or creates items. 

2 Located in the MacPitts program defstructs.l. 



156 



creations of these data structures^ The functions that are implemented in 
the library are only constrained by the designer’s imagination and a bit- 
slice regime. 

The library is used by the lookup-o function to correlate a function 
name found in a <f1acPitts program> with an already created functional form. 
This can be shown in a simple example. Assume that the library is: 

-> (setq library '((libraryHconstant t (nor)) 
(function 1+ ...)(test = ...)))<CR> 

Then the equality test, =, can be found as follows: 

-> (lookup-test library)<CR> 

;; Find the “ = "test definition form in the library. 

(test = ...) 

In summary, MacPitts relies heavily on defstructs. A <MacPitt3 
program> is parsed and converted into a defstruct called an object. The 
five portions of this object are then converted into L5 by different 
programs. A particular set of layout functional units is included as a 
defstruct which contains information relating the unit to MacPitts' syntax 
in the library. A corresponding L5 layout of the unit is found in organelles.l. 
L5 in turn is a language composed of defstructs and layout operators. 

With the general idea in mind of how MacPitts coordinates its various 
parts to produce a chip, consideration is next given to modifying an 
organelle and implementing it functionally. 



In Section VI.B an example will be traced all the way from the layout to 
the test definition. 
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(defstruct definition 
library () 
logo (tent) 
uford-length (value) 
eual (when lisp-form) 
power (pin#) 
ground (pin#) 
phia (pin#) 
phib (pin#) 
pbic (pin#) 
register (name) 
flag (name) 

signal (name direction pin#) 
port (name direction pin#s) 
process (name) 
macro (name type lisp-form) 
constant (name value) 
organelle 

(name #control-lines #parameters 
#test-lines result? gen-form 
sim-form) 

function (name organelle-name types 
control-lines parameters 
interpret-form) 

test (name organelle-name types control- 
lines parameters test-line 
interpret-form) 
label (name process state) 
source (name) 
destination (name)) 

Figure 6.3 definition defstruct 
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B. AN EXAMPLE 

The organelle used in this example was designed by Lieutenant Anthony 
Mullarky using Magic. The approach used was based on (Fox, 1983, p. 32). 
Like Fox, a modification was made to the equality test organelle to reduce 
its size and increase Its speed. The organelle is implemented so that its 
result pulls down the output bus to Vss when the test fails. Two different 
cells are used; bitg and a bit^. The zero bit organelle is a one bit equality 

checker tied to Vdd in order to precharge the output bus to +5 Volts. The Nth 
bit organelle is a one bit equality tester without a pullup. The appellation “ 
== “ is used to differentiate this equality test from MacPitts' “ = ”. 

The first items needed are an organelle----bit-0 and organelle- 
bit-==-blt-n. The organelles were made using Magic and output as GIF. The 
GIF was converter to Gaesar format and then into L5 format. The two 
organelles are shown in Figures 6.4 and 6.5. 

These two organelles are then incorporated into the standard MacPitts 
library. Organelles.l, the compiled portion of the library, is composed of a 
default set of MacPitts functional units in L5 format. Adders, decrementers, 
equality testers, etc., are all located in organelles.l. The L5 layouts are 
usually defsymbols and have a name of the form; lagout-<X>-organelle. 
The two basic zero and Nth bit Items were made into defsymbols without 
any arguments. 

(defun lagout--=-organelle (ratio bit) 

;; Doesn't use the ratio input. 

(cond ((=0 bit)(organelle-»»-bit-0)) 

(t (organelle-»»-bit-n))l) 
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clfplot* Window: Z 10000 -12750 750 Scale; 1 micron is 0.0bbbbb Incnes 1 1 4 .i 1 x > 

blt-0 
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clfplot* Window; 0 10000 -12750 750 Scale; 1 micron Is 0.055556 Inches (1411x) 

blt-N 
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Once this modification is made, then an organelle data structure is 
created and placed into the library (uncompiledl. Recall that an organelle is 
a specific case of a definition defstruct. [Refer to Appendix A] 

(organelle 0 2 1 no 

;; <name> := ==, <^control-11nes> ;= 0, <^parameters> ;= 2 
;j <^test-11nes> := 1, <resu1t?> := no, 

;; The <gen-form> field follows, notice that It is a 
;; functional form. The <gen-form> Is obtained by the 
;; 1ook-up-gen-form function, layout-gen-form creates It. 
;; So, if this whole data structure Is set to ==-test; 

;; -> (setq ==-test ‘(organelle == 0 2 1 no (lambda . . .1 
;; and the gen-form Is extracted and named " create ", 
;;->(setq create (organelle-definitlon-gen-form ==-test)) 
;; -> (apply create ’(Instantiate 0 nil nil nil)) 

;; Will create an Instantiation of the organelle's bit zero, 
(lambda (info bit uiord-lengtb drive ratio) 
(cond 

((eq info ‘instantiate) 

(first-quadrant 

(mirrorn (lagoot-=--organelle ratio bit)))) 
((eq info 'length) 58) 

((eq info ‘midtb) 40) 

((eq info 'inputs) ‘(25 31)) 

((eq info 'output-tgpe) '(ratio)) 

((eq info 'udd) '(43)) 

((eq info gnd) (8 28)) 

((eq info 'dalsg) '(51)) 

((eq info 'test) ‘(51)) 

((eq info ‘conductivitg) 

(cond 

((equal ratio '(4 4)) (quotient 1 0.7759)) 
((equal ratio (8 8)) (quotient 1 0.7604)) 

(t (quotient 1 0.7529)))) 

((eq info '^transistors) '(9 5)) 

(t ()))) 

;; The <s1m-form> Is used by the simulator. 

(lambda (c a b)(list (cond ((== a b) 

(D) (t (0))) ()))) 
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Since " == " is a <test> operator, a test form is created to give the 
organelle functionality. This form is placed in the library along with the 
organelle data structure. The code for <test> '* == " is: 

(teit ” — (integer integer) () 

;; <name> ;= ==, <organelle> := ==, 

;; <types> := (integer integer), <control-lines> := nil 
;; <parameters> ;= ((position l)(position 2)) 

;; <test-line> ;= (physical 1) 

((position 1) (position 2)) (physical I) 

;; <interpret-form> follows: 

(lambda (form uiord-length k g) 

(cond ((or (eg h 'undefined-integer) 

(eq g 'undefined-integer)) 
'undefined-boolean) 

((- « g) t) 

(t f)))) 

A MacPitts program is now run to check this new operator [Figure 6.6]. 

(program five=» 4 

;; Example of a MACPITTS algorithm to test a 4-bit 
;; integer's equality with the number five. 

;; <filename> := f1ve==.mac 

(def 1 1 pouier) 

(def 1 ground) 

(def 2 phia) 

(def 3 phib) 

(def 4 phic) 

(def in port input (5 6 7 8)) 

(def out signal output 9) 

;; A reset pin is needed to initialize the chip. 

(def reset signal input 10) 

(process eqoalitg 0 

first 

(cond 

;; If in " is " == " to 5 then set " out " to t, 

((== in 5)(setq out t)(go first)) 

;; Otherwise, test “ in " again. 

(t (go first)) ) ) ) 
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clfplot* Window: 0 184250 0 213750 Scale: 1 micron Is 0.003 Inches <76x> 

f f ve®= . mac 




Figure 6.6 fiDe-=.mac 
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Figure 6.7 Closeup of == Organelle in fiue= 



.mac 
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Cffplot* Window: 0 184250 0 205750 Scale 

f ! ve® . mac 



The program was run with 
with Figure 6.6. 



and is shown below for comparison 




Figure 6.8 fiue=.mac 
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Figure 6.9 Closeup of = Organelle fiue=.mac 
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In summary, a MacPitts’ functional unit was modified and the changes 
made at different levels were examined. The new " == “ unit was 
significantly smaller that the standard equality organelle. 
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VII. CONCLUSIONS 



This thesis' goal was to examine L5 and show how it is used in two 
silicon compilers: LBS and MacPitts. The thesis showed that L5 is an 
extension of LISP specifically aimed at VLSI synthesis. LISP'S ability to 
treat functions as data to create new operatbrs’was found to be the basis 
for the versatile defstruct data structure generator. The main result of 
the thesis is the incorporation into one document of enough information to 
enable a VLSI designer to automate portions of the layout process or change 
existing MacPitts functions to meet other needs. 

For example, an examination of L5‘s layout primitives and data 
structures showed its compatibility with Caesar and CIF. However, since the 
graphical editor now being used at the Naval Postgraduate School is Magic, a 
method for using this format with L5 is needed. The suggested approach is 
to use the structure of L5 programs that convert Caesar into L5 and vice 
versa; and instead, make the conversion directly from CIF to L5. This would 
make available a larger pool of circuits which have been converted to CIF 
for incorporation into the compilers. Additionally, it would buffer the 
system from other changes in graphical editor file format since CIF is a 
widely used format. 

Many possible changes to MacPitts have been recommended by Carlson, 
Froede and Larrabee; among these suggestions, is to allow pin locations on 
all four sides of the chip. In light of what has been presented in this thesis 
this would be a fairly straightforward alteration. 
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The location of the bonding pads is controlled by the layout-pins 
function in the frame.l section of NacPitts. This program creates a frame 
that determines the architectural implementation of a MacPitts program. It 
places the different structural units into a Vdd/Vss skeleton and 
interconnects them. The input to its top level function, layout-object, 
accepts the object code generated by yet-object in prepass.l. The main 
layout-object function in turn utilizes a layout-pins function [also 

a 

found in frame.l). A program that would place the pins for the user [at 
present they need to be specified) could be written. Other work could 
incorporate different routing schemes into frame.l. 

From this point onward, changes are only limited by the user's 
inventiveness. 
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APPENDIX A: MISCELLANEOUS TOPICS 



A. LAYOUT ERRORS 

There are two types of errors associated with layouts created from 
Nacpitts: either the code has been improperly written, or the output GIF is 
being plotted at the wrong scale. 

An example of improper code is the erroneous specification of Vdd, Vss 
and output locations when a new organelle is created. In Section Vl.B a new 
organelle, " == ", was input into MacPitts. If different parameters [shown in 
Table A.l] had been specified in the organelle structure, then the results of 
Figure A.l would result. Notice that the interconnecting lines have all 
shifted to the right 3 \ units. 



TABLE A.l 

ORGANELLE SPECIFICATION COMPARISON 

Correct Erroneous 

((eq info ’length) 58) ((eq info ’length) 52) 

((eq info ’uiidth) 40) ((eq info ’ividth) 40) 

((eq info ’inpots) ’(26 31)) ((eq info ‘inputs) ’(26 31)) 

((eq info ’udd) '(43)) ((eq info ‘vdd) '(40)) 

((eq info ’gnd) '(8 28)) ((eq info ’gnd) ’(5 25)) 

((eq info ’daisg) ’(51)) ((eq info ’daisg) '(48)) 

((eq info ’test) ‘(51)) ((eq info ’test) '(48)) 

Additionally, the organelle length was specified to be several X units 
longer than the layout actually is, to prevent the output line (when routed 
to the Weinberger array) from shorting with the clock lines [See Figure A.2]. 
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clfplot* Window: 0 184250 0 213750 Scale: 1 micron Is 0.003 Inches (76x> 

ffve = =.mac“Erroneous-*Speclflcatlon 




Figure A.1 fiue==.mac With an Incorrect Organelle Specification 
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The other error type which is encountered is due to improper use of CIF 
plotting routines. For example, if the minimum-feature-size has been 
set to 250 centi-ii/X and plotted using cifplot (which defaults to 200 
centi-]j/X), then plot misalignments will result. It should also be 
remembered that when on-disk storage is selected all items which are 
defsymbols are being created as CIF at the current minimum-feature- 
size. If the user should change the scale size in the middle of creating 
items, then the CIF files will be incompatible. 

Compare Figures A.3 and A.4. In the first figure the pins from 
five=.mac were laid out without any data-path or controller. The 
connections from the clock lines can clearly be seen. This item was created 
using 200 centi-y/X and then plotted using cifplot at this same scale. 
Figure A.4, on the other hand was plotted using 250 centi-p/X. 

B. EXPERIMENTING IN MACPITTS 

A quick look at the use of the layout-object function (in the frame.l 
program) to modify pin locations is used as an introduction to future topics 
of investigation. 

It was seen in Section VI.C that the MacPitts environment is accessible 
because the top-level function is set up to do this as follows: 

% macpitts 

usaye: macpitts <filename> |<options>] 

[Return to top level] 

-> 
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clfplot* Window; 0 164000 0 171800 Scale: 1 micron Is 0.002805 Inches (71x) 

p 1 n-test . ob J 




Figure A.3 fiue=.mac Pins With Correct CIF Scale 
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clfplot* Window: 7600 189000 8850 198750 
p i n-test . ob J 




Figure A.4 fiue=.mac Pins With Erroneous GIF Scale 
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The user now hos all of MacPilts available with the exception of the 
organelles and library. 

Instead of running MacPitts every time a change is made, the 
intermediate object code will be modified. Object code is generated when 
five==.mac is run in the following manner: 

% macpitts obj cif noint noopt-c noopt-d 
nostat fiue=-.mac & > trash 

♦Create an object and CIF file. Redirect comments 
♦to- a trash file. 

Now. assuming that the macpitts environment has been invoked as 

shown above (% macpitts]. two local files that contain commands to 

change UNIX® directories and plot L5 items are loaded. 

-> (include edit.O 
[load edit.l] 
t 

-> (include plot.O 
[load plot.l] 
t 

-> (minimum-feature-size! 200) 

200 

The object file that was generated by MacPitts. five==.obj. is altered by 
setting its data-path and controller to nil. After editing is complete, the 
new file is called pin-test.obj and is shown below; 

-> (euec cat pin-test.obj) 

;;The first portion of the object is definitions 

(((source reset) 

(register sequencer-equality-state) 

(source sequencer-equality-state) 

(destination sequencer-equality-state) 
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(port sequencer-equality-neHt-state internal 

nil) 

(source sequencer-equolity-neHt-state) 
(destination sequencer-equality-nent-state) 
(label first equality 0) 

(destination out) 

(source first) 

(source In) 

(loyo fiue=) 

(uiord-lenyth 4) 

(power II) 

(yround 1) 

(phia 2) 

(phib 3) 

(phic 4) 

(port in input (5 6 7 8)) 

(siynal out output 9) 

(siynal reset input 10) 

(process equality)) 

;; No flags were used In f1ve==.mac 

nil 

;; The data-path portion of five==.obj has been set to nil. 

nil 

;; The control segment has also been set to nil. 

nil 

;; The pin section of the object remains intact. 

((4 (phic)) 

(3 (phib)) 

(2 (phia)) 

(1 (yround)) 

(1 1 (power)) 

(9 (outputs out (siynai-output out))) 

(5 (input (in 3) (port-input in 3))) 

(6 (input (in 2) (port-input in 2))) 

(7 (input (in 1) (port-input in 1))) 

(8 (input (in 0) (port-input in 0))) 

(10 (input reset (siynal-input reset))))) 

This object is turned into an L5 item by the layout-object function 
found in the frame. 1 program. 
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-> (thesis-plot (layout-object 

(read (infile ‘pin-test.obj))) ‘pin-test.obj t) 
;;The standard statistics are output, except the control 
;; unit and data path are empty. 

Statistic - Control has 0 columns 
Statistic - Circuit has 78 transistors 
Statistic - Control has 0 tracks 
Statistic - Pouier consumption Is 0.034114 
Watts 

Statistic - Data-path internal bus uses 0 tracks 
Statistic - Dimensions are 1.640000 mm by 
1.718000 mm 

;; The rest of the output is related to the plotting 
;; function. 

-> Wlndom: 0 164000 0 171800 

Scale: 1 micron is 0.002805 inches (71 n) 

The plot mill be 0.38 feet 

This plot is shown in Figure A.3. The object file is modified again to 
place the pins in different locations: 

-> (enec cat pin-test-2.obJ) 

;; A random pin ordering was chosen. 

(((source reset) 

(reyister sequencer-equality-state) 

(source sequencer-equality-state) 
(destination sequencer-equality-state) 

(port sequencer-equality-nent-state internal 

nil) 

(source sequencer-equality-nent-state) 
(destination sequencer-equality-nent-state) 
(label first equality 0) 

(destination out) 

(source first) 

(source in) 

(loyo fiue=) 

(mord-lenyth 4) 

(pomer 11) 

(yround 1) 

(phia 2) 
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(phib 5) 

(phic 10) 

(port in input (3 4 7 9)) 

(signal out output 8) 

(signal reset input 6) 

(process equalitg)) 
nil 
nil 
nil 

(do (phic)) 

(5 (phib)) 

(2 (phia)) 

(1 (ground)) 

(11 (power)) 

(8 (outputs out (signal-output out))) 

(9 (Input (In 3) (port-input in 3))) 

(7 (input (in 2) (port-input in 2h) 

(4 (input (in 1) (port-input in 1))) 

(3 (input (in 0) (port-input in 0))) 

(6 (input reset (signal-input reset))))) 

The results of this change in pin locations is shown in Figure A.5. The 

intent is not that the user make tedious changes to object code to optimize 

pin layout; but rather, that this process be automated or modified for other 

packaging schemes. 

In summary, this appendix described some observed errors that the user 
should avoid and introduced an area for future work. 
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Figure A.5 fiue=.mac Modified Pins. 
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